Any need for alternative grain boundary (GB) distance metrics than Morawiec 2013? 5DOF property interpolation?

[sgbaird]

I recently developed a 5DOF GB interpolation framework (DOI: 10.1016/j.commatsci.2021.110756) based on grain boundary octonion distances (DOI: 10.1016/j.actamat.2020.05.024) that can compute a 50,000 x 50,000 pairwise distance matrix in ~10 minutes on 6 cores with near identical accuracy to the grain boundary octonion distance. The smooth interpolation is also very fast and accurate with enough GBs (I gave a TMS talk this past Monday in an uncertainty quantification session). I've noticed that GB distances are used in Find GBCD (Metric-Based Approach) and Find Distances to Characteristic Grain Boundaries, perhaps elsewhere.

I'm curious if there's a need/interest for alternative GB distance metrics in DREAM.3D or for 5DOF interpolation/visualization schemes. Also relevant is Shen's recent GB reconstruction scheme from the Rohrer group. It seems like these two could be paired really nicely with EBSD reconstruction techniques (i.e. go straight from EBSD data to a 5DOF grain boundary energy model and visualizations within DREAM.3D), so I thought it was worth asking.

[imikejackson]

This would be an interesting contribution to DREAM.3D.

[imikejackson]

@sgbaird Did you want to try to contribute your codes to DREAM.3D

[sgbaird]

@imikejackson I'm interested in doing so. Right now all the code is in MATLAB (https://GitHub.com/sgbaird-5dof/interp), with lots of vectorized operations, and most of my experience is with higher-level languages. Writing it in C++ might be a bit of a challenge.

[sgbaird]

@oliverkjohnson, do you think there might be an undergraduate with the bandwidth to use MATLAB Coder to generate C++ versions (just for the VFZ distance metric)? Probably no actual C++ experience required.

[oliverkjohnson]

@sgbaird I don't have anyone available right now, but I can keep it in mind if new undergrads apply

[imikejackson]

My experience with the MatLab Coder is that the C++ code that is generated still depends on licensed MatLab libraries. Maybe something has changed in the last few years?

What are your thoughts about writing it in Python?

[sgbaird]

It looks like that may have changed since it allows for outputting source code directly. The linked video makes it seem easy, but who knows until I try for this use case.

I've been meaning to make a Python implementation for at least the distance function, so this would be two birds with one stone for me. Any special requirements or limitations for the Python code (didn't notice instructions in the contributing docs)? For example:

• Is a class preferred?
• Unit test required? (do I just follow something like Image_Histogram.py?)
• Use of Numba package OK?
• Does this make it only available for Python users or can it be used in the GUI/other places as well?

[sgbaird]

Also, in case anyone else comes across this, here is the citation for the (now published) paper:

Baird, S. G.; Homer, E. R.; Fullwood, D. T.; Johnson, O. K. Five Degree-of-Freedom Property Interpolation of Arbitrary Grain Boundaries via Voronoi Fundamental Zone Framework. Computational Materials Science 2021, 200, 110756. https://doi.org/10.1016/j.commatsci.2021.110756.

[imikejackson]

https://github.com/BlueQuartzSoftware/DREAM3D/blob/develop/Documentation/ReferenceManual/6_Developer/python_filter_development_prebuilt.md

We have been quietly letting people know that this exists. Basically it is a conda distribution of DREAM.3D. It enables 2 different use cases.

1. You can write python codes and access the DREAM3D filters/data structures in your python codes. this use case works well if you have an existing python based workflow and you want to programmatically incorporate DREAM.3D into that workflow. Or if you want to generate a whole bunch of synthetic microstructures programmatically.

2. You can write a "Filter" that shows up in the GUI of DREAM3D. Your filter implementation can use what ever python or other libraries needed to get it's job done. I would say try to use a "conda install" of those libraries if possible since that is what we use. Sometimes pip and conda don't get along.

The downsides to either approach is that we are still working on how to actually distribute those filters since they would only really work with the "dream3d-conda" distribution and not a stand-alone distribution of DREAM.3D.

[imikejackson]

@sgbaird Watched the video. I would say if you can get the MatLab codes to pass the coder then that might be the fastest way to generate C++ codes. Then you would just create a DREAM3D C++ filter to collect the inputs from the UI and pass those inputs to the generated code. Maybe worth a try. If you go down this route you will eventually need a full up DREAM.3D C++ Development environment. I would also fork and branch the https://www.github.com/dream3d/DREAM3DReview repository and add your codes in there.

Also don't forget to place a copyright and license at the top of each source file. DREAM3DReview does NOT accept GPL or LGPL license since that would infect the BSD licenses. If you need to release under GPL/LGPL then we can get an entirely new plugin repository for those purposes.