Second method for calculating volumes in FeatureVolumeVectorPostprocessor

[permcody]

Description of the enhancement or error report

@frombs and I discussed a second method for calculating grain volumes for a paper he's working on. We basically still want the ability to calculate volumes according to the field that comes out in FeatureFloodCount UNIQUE_REGIONS (i.e. Each element volume is counted exactly once for the most dominant feature in that element).

Rationale for the enhancement or information for reproducing the error

Second method for calculating volumes of features or grains

Identified impact

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

None, new feature

[frombs]

@permcody - I pulled #7817 to test the new capability. I used the single phase 111 grain dataset. The volume numbers are consistent except for the index flip flop problem we discussed last week. Below is a plot of each grains volumes per time step. You can see that the index suddenly changes at time step 1, 4, and 10 for 3 different grains. This throws off the volume calculations. I think it would be good to address the index issue before we move forward.

[permcody]

We should be able to see that in the output. Do you see any flip flops in the UNIQUE_REGION field? I don't think you will. Now my memory is escaping me on what my theory was here...

Once I remember, this should be fixable. On Thu, Oct 6, 2016 at 9:05 PM frombs notifications@github.com wrote:

@permcody https://github.com/permcody - I pulled #7817 https://github.com/idaholab/moose/pull/7817 to test the new capability. I used the single phase 111 grain dataset. The volume numbers are consistent except for the index flip flop problem we discussed last week. Below is a plot of each grains volumes per time step. You can see that the index suddenly changes at time step 1, 4, and 10 for 3 different grains. This throws off the volume calculations. I think it would be good to address the index issue before we move forward.

[image: flip_flop_index] https://cloud.githubusercontent.com/assets/8171022/19177531/3b0ad640-8c07-11e6-93f2-0f2ff9a9c72d.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7816#issuecomment-252142800, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XIIijjWZ3JBAbHexsOGFEed_h-Fgcks5qxbb8gaJpZM4KPOTh .

[permcody]

Oh, it looks like this happens when a grain gets absorbed. In those cases whatever volume was left of the disappearing grain suddenly gets added to another (nearby) grain. It does seem like it should be a little smoother. On Thu, Oct 6, 2016 at 9:12 PM Cody Permann codypermann@gmail.com wrote:

We should be able to see that in the output. Do you see any flip flops in the UNIQUE_REGION field? I don't think you will. Now my memory is escaping me on what my theory was here...

Once I remember, this should be fixable. On Thu, Oct 6, 2016 at 9:05 PM frombs notifications@github.com wrote:

@permcody https://github.com/permcody - I pulled #7817 https://github.com/idaholab/moose/pull/7817 to test the new capability. I used the single phase 111 grain dataset. The volume numbers are consistent except for the index flip flop problem we discussed last week. Below is a plot of each grains volumes per time step. You can see that the index suddenly changes at time step 1, 4, and 10 for 3 different grains. This throws off the volume calculations. I think it would be good to address the index issue before we move forward.

[image: flip_flop_index] https://cloud.githubusercontent.com/assets/8171022/19177531/3b0ad640-8c07-11e6-93f2-0f2ff9a9c72d.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7816#issuecomment-252142800, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XIIijjWZ3JBAbHexsOGFEed_h-Fgcks5qxbb8gaJpZM4KPOTh .

[frombs]

Yes, I see the flip flops in the UNIQUE_REGION field. This is separate from the small single element grains being absorbed by the larger grains. These are large grains that suddenly disappear and the volume contributions are added to other grains.

For example, in the plot above the grain that is 34 um^2 in area increases suddenly by 6 um^2 at time step 4. The 6 um^2 grain below it (indicated by the red line) suddenly vanishes at the same time. Remapping was turned off for this simulation. This is the same index flip flop problem we discussed in our meeting that you can reproduce with a test called "grain_tracker_refactor_test".

[permcody]

Wait, why was remapping turned off? If two grains with the same OP come in contact that would explain this problem. Is this not just coalesce? You can only safely turn off remapping if you use the same number of OPs as you do grains.

[frombs]

Look at the var_index plot in the attached image and you will see that there is no coalescence. The var_index is not changing but unique_grain is. If you recall, I am taking small times steps to study grain interface smoothing. We decided last month to turn remapping off for this study.

[permcody]

OK - I'll take a look, that should not be happening. This is the existing example or have you made any changes that I need to reproduce?

On Fri, Oct 7, 2016 at 9:45 AM frombs notifications@github.com wrote:

Look at the var_index plot in the attached image and you will see that there is no coalescence. The var_index is not changing but unique_grain is. If you recall, I am taking small times steps to study grain interface smoothing. We decided last month to turn remapping off for this study.

[image: flip_flop2] https://cloud.githubusercontent.com/assets/8171022/19196412/adaf5b10-8c72-11e6-9723-0d37e9c3724a.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7816#issuecomment-252287688, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XILbdqRQz2ei3ILDY984cspRcYYTEks5qxmksgaJpZM4KPOTh .

[frombs]

Here are my files. Take a look at the input file. With all of the changes, it is possible that I missed something simple.

111grains.zip

[permcody]

Brad, I'm able to reproduce. Something is very wrong here and I don't know what it is. I may have to back up a few versions to see where things went wrong because I'm fairly certain we didn't have these flips going on in a recent previous version. I'm running the large Voronoi input file now and I don't see any problems there so it's something specifically with the EBSD data set.

I'll see if I can dig in a little more this weekend.

Cody

On Fri, Oct 7, 2016 at 9:56 AM frombs notifications@github.com wrote:

Here are my files. Take a look at the input file. With all of the changes, it is possible that I missed something simple.

111grains.zip https://github.com/idaholab/moose/files/516563/111grains.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7816#issuecomment-252290491, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XIBqP47bmeF_dIv8-wC98LQdMGbu6ks5qxmuegaJpZM4KPOTh .

[permcody]

@frombs - I still haven't gotten around to looking at this. There is a potential workaround though that can get you going now if you want. If you are only studying grain growth and analyzing volumes you don't really need the EulerAngle tracking or EBSD ID information. You can simply turn off the EulerAngle object and remove the "ebsd_reader" parameter from the grain tracker block and the simulation should work just fine. This probably you found last week is related to the EBSD numbering logic in the grain tracker only as far as I can tell. I'm hoping I can get to this today and tomorrow.

[permcody]

Update: Apparently this problem on the UNIQUE_REGIONS field disappears when remapping is turned on! This is definitely a bug but if you want to just turn remapping back on that should also fix your issue with the volume tracking you are seeing.

[frombs]

I ran both the IN100 and UO2 datasets and verified that remapping does eliminate the flip flop indexing. Can we move on to the void bleed issue and indexing problem with inverse pole coloring?

[permcody]

Remind me what the problem is with the coloring index. I'm not sure there is one. It's possible to recover the actual "feature id" if you use the right method on the EBSDReader. The GrainTracker's job isn't really to show you that information. That being said we could make it available but we'd have to clear that with @dschwen.

As far as the bleed "issue", are you referring to the volume calculation or the UNIQUE_REGION field? There are implications to fixing this. I suppose since we have a special Boolean to turn on the different volume calculation we could work it into there, but changing the behavior of UNIQUE_REGION may not be what we want to do, again, I'll have to check with @dschwen.

On Tue, Oct 11, 2016 at 11:52 AM frombs notifications@github.com wrote:

I ran both the IN100 and UO2 datasets and verified that remapping does eliminate the flip flop indexing. Can we move on to the void bleed issue and indexing problem with inverse pole coloring?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7816#issuecomment-252993013, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XIP7km_c-EAfmXnROSfi49VHtLAMIks5qy8zigaJpZM4KPOTh .

[frombs]

EulerAngleProvider2RGBAux.C needs to be updated with the correct index so that the inverse pole figure maps are displayed correctly. Currently, the indexing is off causing the wrong color to be assigned to the grain. Below is an example. If you start at the bottom left corner, the colors are correct until you reach the cross shaped grain that is circled. That grain is currently being colored red and the index is shifted by 1 for the remaining grains in the dataset.

[frombs]

Both the volume calculation and the unique_region are affected by the bleed issue. This is a special case for datasets with voids. I do not think we should be adding volume contributions or assigning grains to the elements assigned to a void. @dschwen - what do you think?

[permcody]

Yeah, the output above is fine. You are seeing "feature id" on the left and "local id" on the right in @dschwen's terminology. You can convert a local id into a feature id using a different object.

As far as the bleed issue goes. I can put in a line of logic for the existing option in the FeatureVolumeVectorPostprocessor to avoid outputting any volume if there's a phase mismatch. I don't see a problem with that. I don't think we necessarily want to change the "integral volume" technique in general. The bleed issue looks worse than it is, the shape functions on the void have low values so they don't contribute much to the volume, but as far as the display goes, it's either "on or not". Since it's on the border with the void, we currently show the value of the neighboring grains.

[frombs]

To be clear, in order to get the correct inverse pole figure maps, EulerAngleProvider2RGBAux.C needs to be corrected to use "feature_id" instead of "local_id" through an additional object? Should I create a new issue then?

[permcody]

Yes - please do. I believe there's already a way to do that, now whether or not that way makes sense or is easy to do, I don't know. It's worth discussing.

[permcody]

@frombs - I've been really busy this week and I'm on travel next week. I just quickly generated some new code to attempt to handle this void phase problem. I haven't had adequate time to test it but maybe it'll work ;)

The branch is here: https://github.com/permcody/moose/tree/handle_void_phase

What I'm most concerned about is how this will work with adaptivity. I don't have any plans for how to deal with coarser elements along the void interface so don't try to don't try to turn on coarsening. I think you are only doing a convergence study so this branch "should" work for that since you only need refinement. I have a piece of code that attempts to go up the parent pointers for each refined element to find the correct element corresponding to the ebsd mesh resolution before sampling it for the phase. In there is a phase mismatch, the current refined element volume is not added to the current volume computation so this really should stop the bleed over to the void phase.

I checked in a new problem in the phase_field/examples/ebsd_reconstruction folder called "test_problem.i". It runs (barely) but needs several tweaks to get the material properties correct so that it'll actually evolve. You don't have to use that file, you should be able to look at this file and get the pieces you need into your existing simulation. Note the new parameters in the vectorpostprocessor to mask of the void phase. It's not very explanatory but you put the phase number that you want to match in there. Not the opposite phase. Also, this file has the EBSDReaderAvgDataAux object in it which should give you the right feature id instead of using FeatureFloodCountAux for feature information. Note the usage of that object. You have to feed it both the EBSD reader and the Grain Tracker to get it to work.

The bottom line is that this is what you need barring any major bugs I hope. Let me know how it goes.

[frombs]

See issue #7876

On Tue, Oct 11, 2016 at 4:14 PM, Cody Permann notifications@github.com wrote:

Yes - please do. I believe there's already a way to do that, now whether or not that way makes sense or is easy to do, I don't know. It's worth discussing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_idaholab_moose_issues_7816-23issuecomment-2D253062874&d=CwMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=cfRlC-bkBYcDcmBlxJT86aA-h_dr2ZJ37fRGraHZxBw&m=WM9fz8GZ6EJJH_LxhdiTUWRx3e3G2Gi0oAnSJqigG6M&s=sieKW-SW9Ond2nszpo44Fk3YUQ6C2gXe6SOyK7-183k&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AHyuDj5NrT-5F9NNxMqerfJ6zvSVriZ9o6ks5qzAougaJpZM4KPOTh&d=CwMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=cfRlC-bkBYcDcmBlxJT86aA-h_dr2ZJ37fRGraHZxBw&m=WM9fz8GZ6EJJH_LxhdiTUWRx3e3G2Gi0oAnSJqigG6M&s=-_OaZI9WjnORaS_mUvzF0uvUfRoxJkhGgoBUMYPZ0iM&e= .

[frombs]

Cody, I ran the "test_problem.i" and want to provide some feedback. The area of the large grains in the dataset are actually decreasing instead of increasing (I ran it for 10 time steps). I believe the problem in the test is that it is based on the Allen-Cahn model instead of the split Cahn-Hilliard. I suspect the void is actually growing at the expense of the other large grains.

I also tried the code with my split CH input file and saw an increase in area for the large grains as expected. I will report back after adding more refinement and analyzing the results.

[permcody]

Ok, keep me posted On Sun, Oct 16, 2016 at 1:52 PM frombs notifications@github.com wrote:

Cody, I ran the "test_problem.i" and want to provide some feedback. The area of the large grains in the dataset are actually decreasing instead of increasing (I ran it for 10 time steps). I believe the problem in the test is that it is based on the Allen-Cahn model instead of the split Cahn-Hilliard. I suspect the void is actually growing at the expense of the other large grains.

I also tried the code with my split CH input file and saw an increase in area for the large grains as expected. I will report back after adding more refinement and analyzing the results.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/7816#issuecomment-254070033, or mute the thread https://github.com/notifications/unsubscribe-auth/AC5XIHWZvqZ2zQlWleMU8MXUJHR9o69zks5q0oCLgaJpZM4KPOTh .