emsoft-org / emsphinx Goto Github PK

I have run into two issues when trying to index TKD pattern:

mp2sht issue

The mp2sht assumes *.h5 file generated for standard EBSD geometry (backscatter) using EMEBSDmaster etc. When trying to parse h5 file for TKD geometry, errors occur due to the different node naming ('TKDmaster'/'EBSDmaster', 'MCfoil'/'MCOpenCL', etc.). I was able to go around this by renaming the respective nodes in h5 file, but then I ran into another issue:

Tilt check issue

There is a sanity check for abs(90°-sTlt+dTlt) < 90° (i.e. the detector can see the sample). However, for TKD sTlt = -20°and dTlt = 10°, resulting in an error "pattern center not on detector".

Could the TKD geometry be somehow taken into the accout? Thanks!

Hello! Naive question, but I am using EMSphInxEBSD for the first time, or trying to. I followed the download guide and got to 'make -j'. I am on a Windows 10 system, I have installed the latest version of cmake, I also installed make from GnuWin32. When I run 'make -j' I get the following error: make: *** No targets specified and no makefile found. Stop. I have familiarity with Makefiles but see that there are none in the repo. I checked the CMakeFile but working with that is out of the scope of my experience. To check all my bases, I launched VS Code to try the programs and none would work. The include paths are not set correctly, so I am thinking the issue may stem from 'make -j' giving me an error. Any advice on the issue is appreciated.

Even when turning off the SIMD instructions, as suggested in the ReadMe.md file, the programs still do not execute on CentOS7...

./mp2sht
terminate called after throwing an instance of 'std::runtime_error'
what(): failed to read wisdom from .local/share/fftw.wisdom
Aborted

Hello!

The following error occurs at the end of the analysis when running EMSphInx on a .ebsp file. It occurs for both the precompiled binary files and a debug version compiled from source. When I set the batchsize equal to an even factor of the total number of patterns then it completes the analysis without this error.

The Ni example data completes the analysis with any batchsize parameter without issue.

The path specified in this line is incorrect:
https://github.com/EMsoft-org/EMSphInx/blob/master/depends/FFTW.cmake#L158

It is /usr/local/lib/libfft.so

libfft provides .pc files, you should use them insted of guessing the paths yourself.

Dear EMSphInx dev. team,
I am having issues with the GUI on Windows. After using the wizard to create a .nml file, I will try to run the software. A few seconds after executing the command, the application will crash. The .h5 output file seems to save after each time this happens, but nothing else does (.ang, IPF and IQ maps), so it seems that the issue arises when the software attempts to create/save the .ang file. I compared my .nml file to one that works on another machine, and the syntax is identical. I am not sure where the hiccup might be. My .nml file is attached at a .txt file for reference, in the event I am missing something in the output syntax.
EMSphInx_SR027D_Region1_4x4_20230511_dn_nml.txt

All tests pass on osx and linux. The tests for individual values of the Wigner d / D and derivatives (compared to tabulated mathematica results) pass on Windows, but the comparison of individual values against efficiently computed tables fails. The values are very close (~1 or 2 representable floating point numbers away) but not identical as on osx/linux.

Hi all,
I converted the .bcf format EBSD data set into a .hdf5 file format using the converter(bcf2hdf5) developed by Mike Jackson. Unfortunately, EMSphInx could not be able to read the data, obtaining the following error.

Is there any way to handle .h5 files that are converted from .bcf in EMSphInx?

Using the EMSPHINX wizard in version 0.2 to index a scan taken with 5x5 binning causes the binned detector width (taken from the up2 file) to be rounded up from 93.6 pix to 94 pix. This value is unable to be changed (the box is grayed out in the software), so the rounded (incorrect) binned detector width propagates throughout the other calculation steps so that, for instance, the unbinned detector width is calculated to be 470 (94 * 5) when in fact the real value should be 468 (93.6 * 5). This ultimately results in incorrect pattern center values, which causes the final re-indexed scan png to be entirely black despite the fact that the raw confidence indices (when the scan was originally taken) had an average value of 0.5. Fiddling with the pattern center values will get SOME color to show up in the output png, but it's very noisy and still full of black spots.

Some screenshots:

Thanks in advance for the help!

Hi all,

I, as a lot of other people, would be extremely interested in calling EMSphInx from Python. Specifically, I would like to add a spherical indexing method to the EBSD class in our KikuchiPy package (https://github.com/kikuchipy/kikuchipy). I am therefore curious as to what "Python bindings" listed under upcoming features entails. Basically, will this mean I can download EMSphInx from PyPI or Anaconda Cloud and import it like any other Python package? If not, what will be the necessary steps to use EMSphInx?

Håkon

Dear all,
I do not understand what the entry of "patdset" should be in the GUI under "input files".
I only have one HDF5 file from Bruker.

Best,
Andrea

I opened .ang files in OIM Analysis that were created by EMSphInx with two phases selected for indexing, however, OIM Analysis was attributing all pixels to one of the two phases. Looking at the documentation on .ang formatting, OIM Analysis is expecting multiphase files to be labeled starting at phase 1 rather than phase 0. EMSphInx labels the multiple phases starting at phase 0 which seems to signal OIM Analysis to treat the file as containing data for a single phase. That is problematic for processing the data further.

The problem seems to be just the phase numbering because using find & replace to relabel the phases starting at phase 1 was successful in having OIM Analysis correctly read in the data as consisting of multiple phases.

I recently found that when I set normalization to "true":
normed = .TRUE.,�
the indexed IPF map is all black. With it set to 'FALSE', everything runs well.

Does anyone have relevant experience? Or what is the proper way/ trick to use normalized spherical XC?

Thanks,
Fulin

Hello!

I am currently attempting to process a .ebsp file in EMSphinx built from source.

During the 'Preview' process on the first page of the Indexing Wizard I get a vector subscript out of range error. Upon hitting preview.. the process will continue until the very end where the patterns should be displaying.

I have been trying to hunt down the location this particular bug but no luck yet. Any comments on where it could be taking place or what is happening?

I am familiar with the code use and have successfully processed the example data, but with experimental data gathered by our group we get thrown this error.

Thanks for any comments!

Ben

https://github.com/EMsoft-org/EMSphInx/blob/master/CMakeLists.txt#L132

Packaging can only be done off of a tartball, not from a git repository, so the git requirement should be waveable.

Hey Will,

I am interested in opening up the .ang files produced by EMSphInx within the OIM software package. I prefer to use these packages for clean-up and processing. In particular, I am using OIM v8.1.0. When I try to open the .ang produced by SphInx, only the top row of data will appear when I attempt to create IPF or CI maps. I can see that the .ang file does indeed contain all of the data from SphInx, so something is not translating correctly when opening in OIM.

TSL_output.txt
Sphinx_output.txt

Many thanks,
Sean Murray

Hello,

I am encountering an issue when trying to index a .ebsp pattern file that was produced by Oxford AZtec, version 6.0.x. When I try to run IndexEBSD through the command line, I get the following message:

• • • • • • warning: some namelist parameters weren't used: patdset * * * * * *

couldn't determine pixel type for patterns in cc90b00e-a139-462d-8515-02d667ad026e.ebsp

When I try to use the EMSphInxEBSD graphical wizard instead of the command line, the program crashes as soon as I enter the .ebsp filename into the "Pattern File" field. The corresponding terminal output is

Unhandled unknown exception; terminating the application.

These issues occur on both a high-performance compute cluster running CentOS 7 and a laptop running Ubuntu Linux. In both cases, I am using the Debian precompiled binaries for EMSphInx version 0.2. Is the program having difficulty determining the bit depth from the pattern file? I am very interested in getting EMSphInx working with our Oxford EBSD system, so I would welcome any comments or suggestions.

I should note that I have had issues with these AZtec-generated files in EMsoft 5.0.2 as well. In that case, I was able to find a workaround by converting the AZtec .H5OINA file to a NORDIF binary file with kikuchipy. Are there any plans to add NORDIF .dat support to EMSphInx in the future, or any suggestions for getting EMSphInx working with this version of AZtec?

Thanks for your help.

I have downloaded and extracted all files for the asset binary for the GUI for MacOS 10.13+ edition, but any time I try to launch the GUI using the EMSphInxEBSD application file, the app crashes immediately and I cannot get it open. I can provide the error code that accompanies this error message if necessary. TIA!

Hello!

I get the following error when the vendor output file is set to ".ctf". We conduct most of our analysis using .ebsp and .ctf files from the Oxford system, where I first encountered this error. In this example, I managed to reproduce it with the Ni-example data.

The analysis runs to completion without any errors when it is set to ".ang", which I use as a work around at the moment.

Johan