Possible error in the code of plotMap_variantPairs function

[pj-decastro]

Description of the bug
Dear Developers,

Currently I’m working with the plotMap_variantPairs function of ORTools (v.2.3.0) to assess and extract block boundaries. While I was at it, I have noticed that some of the low angle boundaries (around 10°) are being attributed to high angle boundaries, such as V1-V2. Looking into the code, I came across the following (line 42 of plotMap_variantPairs):

variantGrains.prop.variantType = variantGrains.variantId - (variantGrains.packetId-1) * 24/4;

Which, as I understand, re-classifies the other 18 variants into the convention of Morito.
Taking the V1-V4 pairing as an example, I would expect the variants of the same LAGB bain group B1 (i.e. V1-V8, V1-V11) to be attributed to the V1-V4 pairing. However, using the equation above, a V8 variant is being re-classified to a V2, generating a V1-V2 pair. I think this leads to pairing between different packets to be wrong. I am attaching an image example.
Or am I missing something?

Warm regards,
Pedro

Description of the ebsd map
The EBSD is from a bainitic steel with was reconstructed with G-T OR.

Script to reproduce the bug
In this script I select one parent grain after a conventional parent grain reconstruction algorithm like example 07 from ORTools. I have also used another script to calculate the misorientation in a line profile.

% insert the script from this line onward
plot(job.parentGrains); % Find the grain Id you want.
goi = job.parentGrains('id',204); %This has to be filled manually with the Id selected
goiId = goi.id;
goip = job.ebsd(goi);
goip = goip(job.csParent);
goic = job.ebsdPrior(job.ebsdPrior.id2ind(goip.id));
plot(goic('AlphaP'),goic('AlphaP').orientations);
[variantBoundaries_PAG, PAG] = plotMap_variantPairs(job,'parentGrainId',goiId,'linewidth',2);
V1V2 = variantBoundaries_PAG{1,1};
V1V3 = variantBoundaries_PAG{1,2};
V1V6 = variantBoundaries_PAG{1,3};
V1V4 = variantBoundaries_PAG{1,4};
condV1V4 = V1V4('AlphaP','AlphaP').misorientation.angle >= 2.5 * degree &...
    V1V4('AlphaP','AlphaP').misorientation.angle < 15 * degree;
V1V4b = V1V4(condV1V4);
%% Plot desired variant boundaries on an EBSD level
figure;
%plot(goi,goi.meanOrientation); %Austenite remains in the background.
%hold on
plot(goic('AlphaP'),goic('AlphaP').orientations);
hold all % The colors bellow match the plotMap_variantPairs color coding.
plot(V1V2,'lineWidth',1.25,'linecolor','r');
plot(V1V3,'lineWidth',1.25,'linecolor','g');
%plot(V1V4,'lineWidth',1.25,'linecolor','w');
plot(V1V6,'lineWidth',1.25,'linecolor','b');
plot(V1V4b,'lineWidth',1.25,'linecolor','y');

...
...

Current behavior
Unexpected variant pairings.

Expected behavior
Pairings to be done between variants with expected misorientation relationship.

Error message (if any)
Please insert the errors in-between the lines bounded by the backticks ( ``...):

% insert the error message from this line onward
...
...

Screenshots (if any)
I am plotting here three images of the same prior austenite grain, one with the approach from the code above, and the other plotting the LAGB (2.5° to 15°) obtained via conventional calcGrains. The red line shows a misorientation analysis. It can be seen that a LAGB is shown as V1V3 pair by the code.

The blue arrow bellow is not related to the main topic but I thought I should mention it. I have commented about it in the additional comments section.

MTEX version:
Version 5.10.2, ORTools 2.3.0

Any other additional comments
One additional thing that I have noticed, is that some LAGB are actually not being detected with the boundaries obtained from plotMap_variantPairs, I have pointed that with an arrow in both figures, the LAGB is shown with the calcGrains approach.

[AzdiarGazder]

Hi @pj-decastro,

First off, thank you so much for providing detailed information on your issue.
This has helped @frankNiessen and I immensely in understanding the problem.
We are both of the opinion that the problem is not a bug per se, but rather an issue of applicability.

In ORTools, the plotMap_variantPairs function stems from the following references:

• S. Morito, H. Tanaka, R. Konishi, T. Furuhara, & T. Maki, The morphology and crystallography of lath martensite in Fe-C alloys. Acta Materialia, 51(6), 2003, 1789–1799.
• S. Morito, A.H. Pham, T. Hayashi, T. Ohba, Block boundary analyses to identify martensite and bainite, Mater. Today Proc., 2(3), 2015, S913-S916.

In both these papers, there are a few implicit assumptions:

• that the microstructure being analysed is lath martensite, and
• that the operative OR is the theoretical and rational Kurdjumov-Sachs orientation relationship, and
• that there are 6 variant types within each packet (V1-V6, V7-V12, V13-V18, V19-V24), and
• that the analysis is not readily extendable or applicable to other microstructures, (for instance plate martensite, where the concept of packets is quite different).

---

In your case, the microstructure is bainitic and the operative OR is the irrational Greninger-Troijano orientation relationship.
Therefore, the plotMap_variantPairs function is not directly applicable, and especially more so when irrational ORs (other than K-S) are considered operational.

Your issue however, highlighted the need to change the function name in order to make its description clearer to users.
When this function is called, we will now also include a warning (outputted to the command window) to ensure that it is only applied to lath martensite microstructures.

Lastly, we should also point out a current limitation with the plotMap_variantPairs function that was first identified by Dr Tuomo Nyyssönen.
Currently, for each grain, variant pairs are computed without discriminating between crystallographic packets (CPs). Thus, variant pairs at boundaries between CPs are included in this output.
In a future improved function implementation, for each grain, only variant pairs within each CP will be considered. Variant pairs at boundaries between CPs will be excluded by default (unless specified by the user).

**Lastly, and importantly, if an explanation from the maintainers resolves your issue, please press the "Mark as answer" button on the appropriate response. Your assistance in this regard enables us to close discussions as complete. **

Hope this helps.

Warm regards,
Azdi

[frankNiessen]

Closing this - resolved in 9c941bd