search

EMsoft-org / EMsoft

Public EMsoft repository
Other
61 stars 94 forks source link

Lower indexing Success Rate for same patterns and master pattern after nightly build Sept. 13 #91

Closed hakonanes closed 4 years ago

hakonanes commented 4 years ago

I experience worse EBSDDI indexing results with EMsoft 5.0 than with 4.2, i.e. a lower Indexing Success Rate (ISR) of 64% compared to 100% for the latter, with the same Ni experimental patterns, master pattern and NML input file.

After going through the nightly builds for Windows and re-indexing the same ROI, the ISR dropped to 64% with the nightly build 2019-09-13. For 2019-09-12 the ISR was 100%.

Does anyone else experience this? I don't know the root of the problem. I see that a series of commits with changes to the point of view (EBSD-detector) were made on the 12th. Do I have to change my pattern centre definition after these changes?

Relevant files are available here: http://folk.ntnu.no/hakonwii/files/emsoft_issue/ (dot product and ang files produced by the nightly builds are in the directories 4_3_9_12 and _13).

marcdegraef commented 4 years ago

Is it just the isr number that is lower, or do you actually have a different indexing result in the ang/ctf file as well? (haven't had time to look at your posted files yet)

Marc.

On 10/16/19 9:30 AM, Håkon Ånes wrote:

I experience worse EBSDDI indexing results with EMsoft 5.0 than with 4.2, i.e. a lower Indexing Success Rate (ISR) of 64% compared to 100% for the latter, with the same Ni experimental patterns, master pattern and NML input file.

After going through the nightly builds for Windows and re-indexing the same ROI, the ISR dropped to 64% with the nightly build 2019-09-13 http://www.bluequartz.net/binaries/EMsoft/experimental/2019-09-13/. For 2019-09-12 the ISR was 100%.

Does anyone else experience this? I don't know the root of the problem. I see that a series of commits with changes to the point of view (EBSD-detector) were made on the 12th. Do I have to change my pattern centre definition after these changes?

Relevant files are available here: http://folk.ntnu.no/hakonwii/files/emsoft_issue/ (dot product and ang files produced by the nightly builds are in the directories 4_3_9_12 and _13).

— 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/91?email_source=notifications&email_token=AB26VWAVGLUVAQDOMWZWEIDQO4JQJA5CNFSM4JBLRXSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HSFHPDA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB26VWCYZJXHRWYSGYPY6STQO4JQJANCNFSM4JBLRXSA.

hakonanes commented 4 years ago

Thanks for the quick reply! Yes, I get different orientations as well. I have included quality metric maps and orientation maps in the result directories in the above link.

1st row: orientation similarity maps, 2nd row: inverse pole figure maps with respect to out of plane direction. Produced from ANG file in result directories.

Nightly build 2019-09-12, ISR = 100% Nightly build 2019-09-13, ISR = 64%
osm_4_3_9_12 osm_4_3_9_13
omzc_ni omzc_ni
marcdegraef commented 4 years ago

ok, so a first comparison on Mac OS X between the nighty build from 9/11/19 and the current release 5.0 from today reveals no major differences when done on the same data set with the same input nml file. There are small angle differences (they shouldn't be there so perhaps this points to an issue of some kind), but the ISR in both cases is 99.8% and the IPF maps are virtually indistinguishable... I'll keep looking. Marc.

marcdegraef commented 4 years ago

Just to make sure, did you also try to run this with the latest nightly build or only with the one from 9/13? Around that time we were making a lot of changes so it is possible that you ended up running with an incorrect or partially modified version of the program... just trying to eliminate possible causes...

hakonanes commented 4 years ago

Thank you so much for taking the time to test during these realese times.

I get the same results with the latest nightly build 2019-10-17 for Windows with my own data in the above link. However, with your DI tutorial Scan 6 with the same build, I get an ISR of 99% from a small ROI... which points to something wrong with my data set, NML file or master pattern. I'm trying out another Ni data set now.

marcdegraef commented 4 years ago

ok, thanks for letting me know. Looking at your EMEBSD.nml file, is the L value really 2087? That seems really small to me...

hakonanes commented 4 years ago

The specimen-detector distance is about 17 000 um, but the detector (70 um pixel size) is binned 8 times (480 -> 60), and I always use binning = 1 in the EBSDDI input NML file. Thus I have scaled the L, numsx, numsy, xpc and ypc accordingly. I have kept delta = 70, with success up to the mentioned nightly build. However, based on the discussion in the Google Group I apparently should scale delta, i.e. set it to delta = 560? Using this delta yields an access violation error.

hakonanes commented 4 years ago

So I believe I have narrowed my problems down to a difference in simulated patterns from the same pattern centre... Results from EMEBSD on Ubuntu with source code version before commits on the 12th and the latest as of today (18th October 2019). Both patterns have (xpc, ypc, L) = (-43.01, 138.24, 16507.68).

4.3 (2019-09-12) 5.0 (2019-10-18),
4_3 5_0

I have updated the above link with the EMEBSD NML input files and resultant H5 files, with also the images: http://folk.ntnu.no/hakonwii/files/emsoft_issue/pattern_centre/

Interestingly, by switching signs on xpc in 5.0, I get the same pattern as from 4.3... Were there made some sign changes on the 12th, which might be the cause of this?

marcdegraef commented 4 years ago

Yes, there was a sign change in the internal use of xpc; this was necessary because we changed our computational view point for EBSD patterns from the original approach (looking at the detector from the sample) to the current approach, also used by the vendors (looking at the sample from the CCD chip "through" the scintillator). This required a change in one of the reference frames with as a result a sign change in the xpc pattern center coordinate.

hakonanes commented 4 years ago

Thanks for clarifying, so this sign change only affects the internal use of xpc, no change of sign is necessary on the user's part, i.e. PC equations in the tutorial paper still apply?

marcdegraef commented 4 years ago

They should still apply... but let me know if you find that they don't.

hakonanes commented 4 years ago

I have to change sign of xpc to get indexing corresponding to results from TSL, see inverse pole figures, coloured with respect to out of plane direction, for an Ni dataset indexed with TSL and with xpc negative/positive. All results from 5_0_20191018_0. The right column is with xpc as before/from PC equation in tutorial paper.

TSL, x* = 0.567 xpc = -5.12 xpc = 5.12
omzc_ni omzc_ni omzc_ni
marcdegraef commented 4 years ago

ok, thanks for digging into that issue. I will post a message on the main page, stating that with respect to older indexing runs, the x-pattern center variable needs to be negated in release 5.0 and onward... This is a consequence of the change of reference frame to be consistent with the vendors... When we first made the reference frame choice in 2013, we didn't pay attention to the vendor conventions and we probably should have done that.

hakonanes commented 4 years ago

Aha, so it is not just me who get incorrect results with 5.0 with e.g. xpc = Nx*(xstar - 0.5) for TSL... I'm curious, so it is not satisfactory to keep this as in the tutorial paper but negate it internally?

hakonanes commented 4 years ago

Okay, closing this. Thanks so much for the quick responses, and ultimately the solution.