Second method for calculating volumes in FeatureVolumeVectorPostprocessor #7816
Comments
permcody
added
T: task
New method in FeatureVolumeVectorPostprocessor that is less accurate but conservative over the domain closes idaholab#7816
|
@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.
|
|
We should be able to see that in the output. Do you see any flip flops in Once I remember, this should be fixable.
|
|
Oh, it looks like this happens when a grain gets absorbed. In those cases
|
|
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". |
|
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. |
|
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.
|
|
OK - I'll take a look, that should not be happening. This is the existing On Fri, Oct 7, 2016 at 9:45 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. |
|
Brad, I'm able to reproduce. Something is very wrong here and I don't know 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, 111grains.zip https://github.com/idaholab/moose/files/516563/111grains.zip — |
|
@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. |
|
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. |
|
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? |
|
Remind me what the problem is with the coloring index. I'm not sure there As far as the bleed "issue", are you referring to the volume calculation or On Tue, Oct 11, 2016 at 11:52 AM frombs notifications@github.com wrote:
|
|
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.
|
|
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? |
|
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 |
|
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? |
|
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. |
|
@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: 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 The bottom line is that this is what you need barring any major bugs I hope. Let me know how it goes. |
|
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. |
|
Ok, keep me posted
|
These tests occasionally fail on Macs. I looked into it, and it appears that the recursion is chewing up a lot of stack space with all of the adpativity that these tests have. For some odd reason, this sometimes causes the Mac tests to just run out of memory? Adding more procs makes these tests more stable. refs idaholab#7816
These tests occasionally fail on Macs. I looked into it, and it appears that the recursion is chewing up a lot of stack space with all of the adpativity that these tests have. For some odd reason, this sometimes causes the Mac tests to just run out of memory? Adding more procs makes these tests more stable. refs idaholab#7816
These tests occasionally fail on Macs. I looked into it, and it appears that the recursion is chewing up a lot of stack space with all of the adpativity that these tests have. For some odd reason, this sometimes causes the Mac tests to just run out of memory? Adding more procs makes these tests more stable. Additionally, forcing the test to run in parallel uncovered a nasty bug that would only be present with this test in a parallel run! refs idaholab#7816
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
The text was updated successfully, but these errors were encountered: