Dictionary Indexing dot products may be incorrectly sorted

[marcdegraef]

The maximum dot product listed on the command line during the program runs does not appear to agree with the actual largest dot products in the output file. Perhaps there is an issue with the sorting code?

[epang22]

TopMatchIndices (in hdf5 outputted by EMEBSDDI) does not always go from 1 to max # of dot products saved (sometimes get repeat numbers, sometimes get numbers too large). This is an issue if you try to compute dot products for many euler angles and then extract the dot products for each of them. We have noticed that this issue only occurs for certain numbers of orientations requested, number of patterns to index, nthreads, and numexptsingle/numdictsingle (but some combinations seem to be ok). We have some matlab code that loops through parameters and tests for this error that may be helpful in troubleshooting: https://github.com/epang22/EMsoft-utilities/blob/master/EMsoft_v4_3/TestErrorsTimings.m

[marcdegraef]

Would you be willing to share the output of this program run? I should have some time in the next week to try and track this bug down...

[epang22]

Upon further examination, it seems that the issue only occurs when some patterns in the dataset are completely black (we were using blank dummy patterns), and the zero dot products lead to unexpected TopMatchIndices. It's an easy fix on my part to work around it (just don't have black dummy patterns), so no rush. But here are some output .hdf5 files that illustrate the weird behavior: https://www.dropbox.com/s/isn0hlivl5r91sc/DIoutput.zip?dl=0

Thanks for the quick response and taking a look at this!

[saransh13]

I think it’s the ssort routine which is causing this, when all the dot products are the same, and it tries to rank them. I think a simple solution would be to define a default behavior when all the values to be sorted are the same.

Saransh

On Fri, Mar 13, 2020 at 12:25 PM Edward Pang [email protected] wrote:

Upon further examination, it seems that the issue only occurs when some patterns in the dataset are completely black (we were using blank dummy patterns), and the zero dot products lead to unexpected TopMatchIndices. It's an easy fix on my part to work around it (just don't have black dummy patterns), so no rush. But here are some output .hdf5 files that illustrate the weird behavior: https://www.dropbox.com/s/isn0hlivl5r91sc/DIoutput.zip?dl=0 [image: summary] https://user-images.githubusercontent.com/53325250/76653230-a4791d80-653e-11ea-9964-fe0b152e6f73.PNG

Thanks for the quick response and taking a look at this!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/EMsoft-org/EMsoft/issues/39#issuecomment-598877737, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADYZ2U5GQW5L4TEQHPLMECLRHKCCBANCNFSM4GE324AA .