AZtecCrystal data export and Grain boundary fitting issues

[kata-neumann]

We have encountered the issue with data import into the DefDAP while our data are exported from AZtecCrystal v2.1 and return an error message (please below). When we use the same EBSD data exported from AZtec v5.1 it works well. We use the AZtecCrystal to crop the initial EBSD map just to the area where the DIC image acquisition was performed. What can be done to avoid the error message? Is it necessary to crop the initial EBSD data which are covering a significantly large area than DIC?

The second issue is related to the grain boundary fitting to a DIC map. After we select homologous points, the grain boundaries do not fit well on the DIC map (see below). Only the grain boundary fragments are shown in the final image. What can be the reason since we provided high-quality EBSD maps with a minimum of zero solution points? It should be also noted that obtained transformation matrix after DefDAP resolved homologous points between the EBSD map and SEM image, is significantly smaller than the reference and shifted from the central position of the plot. Could this be the reason for not completing the grain boundary overlay on the DIC map? Or can some issues originate from the SEM (pattern) image (we use a SE-detector image instead of a BSE one)?

More general questions:

• Does the program work reliably for larger strains such as 7pct and higher? I have seen the articles where DefDap was utilized and usually the tests were conducted at a lower strain level compared to our studies.
• Is there some margin of tolerance in DIC pixel size and EBSD step size? Do they have to be approximately equal?

[mikesmic]

1. The error you had with loading your EBSD files should work with the latest stable version (0.93.4), please try that version. Note that you may have to look through the example notebook again as some of the commands may have changed slightly.

2. You seem to be having two issues with the EBSD map. I think your EBSD pixel size must be significantly smaller than for your DIC map, so as EBSD 'image' data is interpolated to the DIC frame some of the finer features are being lost. We did start playing around with transforming a vector based representation of GBs but from memory that can't be used in the grain detection algorithm on the DIC map so you may come into issues with that also. As for the GB matching issue you will really have to show more about the homologous points you have selected and how confident you are that they represent the same material location in both datasets.

3. This probably depends on how heterogeneous the deformation is. I don't think 7 % will be an issue though but you would have to try.

4. As in point 2, a large difference between pixel sizes can cause issues. We have created workarounds for DIC pixel size << EBSD pixel size as this is typical of the data we collect. The vector based grain boundary representation is the best way to fix this issue but this is not finished.

[kata-neumann]

Thank you for your advice, we have tried it and have some updates. Indeed, our EBSD step size is smaller than the DIC map (more than twice), therefore this can be the source of our issues. We also tried resizing the DIC map (up to DIC step size 0.244 micron) and the overall image but the grain boundaries still do not match.

Resolutions (in pixels) and pixel/step sizes of our data:

• EBSD map: 1500x1450; step size 0.2 micron
• DIC map: 530x530; pixel size 0.48 micron
• overall(pattern) image: 512x512; pixel size 0.58 micron

The image below shows the set-up of the homologous points in figures 15 and 16 (overall SE image and EBSD, respectively) and the reference matrix with the transformation matrix. As you can see, the transformation matrix is in the upper left corner of the image and it is significantly smaller. It is obvious, that the grain boundaries do not correspond to the DIC map in the figure 21, as I mentioned before.
I uploaded our data to the following link if you want to try it by yourself. I will be very grateful if you would cross-check whether I do not make some elementary mistake while using the DefDAP.

[kata-neumann]

Hello,
We have been working on
data processing by DefDAP for a long time. We have performed a new tensile test where we acquired DIC and EBSD maps and pattern images at various resolutions in order to fulfill your suggestion to get similar pixel sizes for each of them. We have tried multiple combinations, however, we still have trouble merging DIC and EBSD datasets, as you can see in the images (I sent in the attached file). The file also includes a detailed description of what data/parameters were used. We tried many variations through EBSD, DIC, and pattern size, but still without any satisfying results.
Do you have any idea where the issue might be?
DefDap-issue_info.pptx

[mikesmic]

Hi @kata-neumann sorry that you are still having issues with your data alignment. I have looked briefly at your slides. On slide 2 I'm not convinced that the BS image is from the same region as the DIC map. In the DIC map middle, left I can see some straight (probably twin) boundaries where the slip bands change direction but I cannot see these boundaries in the same location of the BS image. The pattern image must be the reference image you applied the correlation to (only perhaps with the pixels binned to create a more manageable size, which is then set when setting the image path). I'm happy to have a call to try and get this issue sorted for you, just send me an email (michael.atkinson@manchester.ac.uk).

[rhysgt]

Hi Kata,

It looks like you are getting close! To add to what Michael said, another key thing to getting an accurate match between the pattern/DIC and the EBSD map are the parameters on setPatternPath. The second argument 'windowSize' gives the scaling between the pattern image and the DIC data. This is the size of a pixel in pattern image relative to pixel size of DIC data i.e 1 means they are the same size and 2 means the pixels in the pattern are half the size of the dic data. I think you have used the EBSD/pattern ratio which will not give the correct result?