Closed j2bradley closed 9 years ago
Seems fine to me, I'll see if I can dig up my previous unmerged solution to this issue.
@jhbradley, I was just looking at the GrainTracker to see if I could remember how I handled this situation and realized that my solution DID get merged. I maintain another map on top of the "grain id" to map to the possibly non-unique "ebsd id". I believe it works with the one dataset that Brad gave me but it hasn't be tested extensively. If you have another dataset that's failing, I'll need to take a look at it.
Is it possible that he is just not using this additional layer of mapping?
It's automatic if you are using the EBSD reader option.
The data set I am using is in moose/modules/phase_field/examples/ebsd_reconstruction/IN100_128x128.txt
On Thu, Sep 3, 2015 at 4:00 PM, Cody Permann notifications@github.com wrote:
It's automatic if you are using the EBSD reader option.
— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5651#issuecomment-137585981.
That's the example that Brad and I worked on when we encountered this problem. I just fired it up and besides the error on the "output_postprocessors_on" syntax (which I just fixed and checked in), it appears to be running fine. That particular EBSD dataset has exactly 111 grains but the grain tracker sees 114 (you'll see that when you run the simulation). The GrainTracker logic sees this and properly maps those remaining grains back to the proper EBSD ids.
The "unique grain id" is exactly that a unique number (in this case up to 114). However when you actually ask for the grain number through the API, you'll get a number between (0,111].
If you are still having issues or need further explanation, feel free to stop by.
Cody
On Thu, Sep 3, 2015 at 4:41 PM John-Michael H. Bradley < notifications@github.com> wrote:
The data set I am using is in moose/modules/phase_field/examples/ebsd_reconstruction/IN100_128x128.txt
On Thu, Sep 3, 2015 at 4:00 PM, Cody Permann notifications@github.com wrote:
It's automatic if you are using the EBSD reader option.
— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5651#issuecomment-137585981.
— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5651#issuecomment-137593143.
Will do. Thanks for your time!
On Tue, Sep 8, 2015 at 9:14 AM, Cody Permann notifications@github.com wrote:
That's the example that Brad and I worked on when we encountered this problem. I just fired it up and besides the error on the "output_postprocessors_on" syntax (which I just fixed and checked in), it appears to be running fine. That particular EBSD dataset has exactly 111 grains but the grain tracker sees 114 (you'll see that when you run the simulation). The GrainTracker logic sees this and properly maps those remaining grains back to the proper EBSD ids.
The "unique grain id" is exactly that a unique number (in this case up to 114). However when you actually ask for the grain number through the API, you'll get a number between (0,111].
If you are still having issues or need further explanation, feel free to stop by.
Cody
On Thu, Sep 3, 2015 at 4:41 PM John-Michael H. Bradley < notifications@github.com> wrote:
The data set I am using is in moose/modules/phase_field/examples/ebsd_reconstruction/IN100_128x128.txt
On Thu, Sep 3, 2015 at 4:00 PM, Cody Permann notifications@github.com wrote:
It's automatic if you are using the EBSD reader option.
— Reply to this email directly or view it on GitHub <https://github.com/idaholab/moose/issues/5651#issuecomment-137585981 .
— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5651#issuecomment-137593143.
— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5651#issuecomment-138596681.
If you find an actual issue, please feel free to reopen.
Grain Tracker needs to be able to handle multiple occurrences of the same grain id when these occurrences belong to the same grain (as in the case of kidney-shaped grains when dealing with serial sections). Otherwise there is a mismatch between the EBSD centers and the Grain Tracker Centers. I believe @permcody will be handling this.