Potential enhancements to post-processing scripts, particularly MatchGrains

[StopkaKris]

Hi Hemant,

I have been using the MatchGrains script to match grains across load states. Although the user can provide a text file with multiple Grains.csv paths and then provide the beam height and the offset between adjacent FF scan states, I took a slightly different approach, described below. This had me thinking about potential enhancements to this script.

When a specimen at the beamline undergoes loading, for example in the RAMS device, grains in a certain FF scan volume will no longer be within the same scan volume if the applied load to the specimen causes significant translation. Furthermore, grains at the "top" of the specimen will be displaced to a greater degree compared to grains at the bottom of the specimen, assuming the experimental setup fixes the bottom grip and applies displacement to the top grip. Therefore, I found the feature to provide a text file of Grains.csv paths, beam height, and offsets in the X, Y, and Z directions inadequate for my use case.

As an alternative, I first determined the translation of my specimen in the X, Y, and Z directions at subsequent load states using tomography scans, accounting for both specimen translation and deformation. This can be done by finding features of interest and tracking their spatial evolution. I then manually edited grain centroids at loaded states directly from the Grains.csv files and aggregated all grains from all layers at a given load state into a single Grains_aggregated.csv file. I also appended a column to this new .csv file called "layer" that tracks the original layer in which each grain was detected. So to summarize, the Grains_aggregated.csv file at the initial/unloaded state is a simple aggregation of Grains.csv files from all layers. At the loaded states, the Grains_aggregated.csv files also account for specimen translation and deformation in the X, Y, and Z directions such that grains are as close as possible in 3D space to their matches in the unloaded state.

The figure below quantities the necessary grain centroid translation in the negative Z direction (within the MIDAS coordinate system) at a loaded state. Grains near the "top" of the specimen are displaced further than those at the "bottom" of the specimen. While the difference across the entire specimen is only about 30 microns (this captures specimen deformation), it is still a good way to get the most reliable grain matches across load states. I can describe more details on how this figure was generated if anyone is interested.

I have Grains_aggregated.csv files for the unloaded state and all loaded states, and in the latter states, the grain centroids have been shifted to account for specimen translation and deformation. I now wish to feed these files into MatchGrains. However, the script currently pulls the grain IDs assigned during individual FF layer reconstructions, and the problem is that there are repeated grain IDs when aggregating the Grains.csv files. The original motivation behind this post was to determine a way to get around this.

Potential script enhancements:

1. Allow the user to aggregate all Grains.csv files from multiple layers at a given load state into a single Grains_aggregated.csv file (perhaps this would be a separate script). In the process of doing so, assign new grain IDs unique to this load state to prevent duplicate grain IDs.
2. Allow the user to specify two constants to more accurately account for grain translation and deformation at loaded states, according to the figure above. The user can determine this offset however they choose, e.g., tomography, DIC, etc.
3. Modify MatchGrains such that it can account for duplicate grain IDs in a Grains_aggregated.csv file. This could be assigning new grain IDs unique to each load state, or a part of the code that reads the final, appended column in Grains_aggregated.csv which contains the layer number in which each grain was detected.

I am happy to discuss these suggestions further.

Best regards,
Kris

Krzysztof Stopka

[junspark]

So this was something we used to do in the older version of grain matching script where Grains.csv files from a load were aggregated first with known Y offset (and assigned grainID + layer_nr*1000000 as a new grain ID) and compared to aggregated grains from another load step.

In principle this worked ok but with some issues:
a) when a grain appears in two layers they need to be merged appropriately first (and what I mean by appropriate can be different than what others think) in the aggregation step.
b) we typically think the Y offset (vertical motion) is known but what I've found is that with focused beam, this might not be the case.

I support adding the feature that is proposed here but these caveats need to be explained (whether one reads it or not is a different story).

[junspark]

Also, what I found is that astronomers are really good at tracking small, faint objects over time on time-lapse photographs. I wonder what and how they do this operation. You guys know any astronomers?

[marinerhemant]

I agree this can be a helpful improvement. We had a few users who used what Jun mentioned, but inter-layer grain merging still needs to be standardized. We can discuss how to do this best.

I propose a more interactive experience for users: We can add a Python wrapper around this code, allowing users to run things interactively. The MatchGrains code would be called with the proper arguments at the end of the Python wrapper. Interactive C-codes can be time-consuming and redundant. We can add 3d offsets, scaling factors, load numbers, etc in the Python script. The C-code command would become too long; Python would be easier to define and then call the C-code. The advantage of C is the speed, it can go through 10,000 grain pairs in a few seconds, Matlab or Python are very slow.

The Python script can also make it easier for users to run with more options: twin merging, inter-layer merging, etc.

Astronomers have it easy; they don't have orientations to match. Object tracking in 2D might be an easier problem.

[StopkaKris]

Hi guys,

Thanks for sharing your thoughts on this. And a python wrapper would be a great addition. I would be happy to discuss further, help you implement these code enhancements, and test using my data set. The inter-layer grain merging is especially interesting. I know Javi did this manually for his data set, but I'm sure there could be a nice automated way to do this.

Best regards,
Kris