Difference in Grain Count and Grain IDs When Loading DREAM3D Files with DAMASK and h5py

[hugy888]

Hi,
I've encountered an issue when loading DREAM3D files of polycrystals. I used damask.Grid.load_DREAM3D() to load the files, and I noticed that the number of grains (# materials: 1143) identified by DAMASK is different from the count I get when using h5py (# materials: 1164). Could someone explain why DAMASK and h5py might be reporting different grain counts?

Furthermore, there seems to be a discrepancy in the grain ID arrays obtained from these two methods. The grain_id_damask array starts at 0, while the grain_id_h5read from h5py starts at 1. During the loading or simulation process, does DAMASK assign the first material from material.yaml as grain_id=0? Also, how does DAMASK assign each material to a grain ID—is it based on the order in material.yaml?

I've attached a snippet of my code and the outputs for reference:

I appreciate any insights or guidance on this matter.
Thanks

[sharanroongta]

Hi,

First I try to answer the second part of your question: Grain ID does start from 0, and it is mapped to the material list in material.yaml. So you have understood this correctly.

As far as the first query is concerned:
Maybe @vitesh13 can provide some insight, who has more experience with DREAM3D data.

Hope this helps.
Thanks

[vitesh13]

Hi,

I just tried out the load_DREAM3D function in the latest version and it works fine. I get the correct grain IDs.

To help us understand the problem and test the code, it would be great if you can mention the DAMASK version that you are using and also attach the Dream3D file which is raising this error.

[hugy888]

Thanks for your response and suggestion. I've tried specifying the name of the dataset as you mentioned, and indeed, the grain counts match perfectly in both versions of DAMASK.

However, there are still differences in the two numpy arrays regarding the grain IDs, as illustrated below:

Interestingly, the bincount results of these arrays are identical, suggesting that the number of voxels for each grain ID is the same across both methods. This leads me to think that perhaps a rotation or some other transformation is applied during the Dream3D file loading process, since the grain size distribution for each grain ID corresponds exactly.

Could there be a transformation step that I might be overlooking? Any further insights on this would be greatly appreciated.

Best regards.

[eisenlohr]

@hugy888

Important

Please always paste editable code snippets instead of screen shots.
This makes reusing and debugging your code much easier for the next person.

Example based on the screenshot above:

comparison_bincount = np.bincount(grain_id_damask.reshape(-1)) == np.bincount(grain_id_h5read.reshape(-1))
print(comparison_bincount.all())

[eisenlohr]

I suspect that you are observing the difference in indexing order between DAMASK and Dream3D. Please try

(grain_id_damask.flatten('F') == grain_id_h5read.flatten('C')).all()

DAMASK sorts with "x" being the fastest index, i.e. Fortran-style or column-major order, whereas Dream3D likely uses "z" as fastest index, i.e. C-style or row-major order (which happens to be the default for flatten and, equivalently, reshape(-1)).

Caution

Hence, when feeding a flattened data array into a visualization pipeline, say pyvista or such, you need to be certain that the order you are providing is the order that is expected. Otherwise, you are inadvertently switching the "x" and "z" coordinate axes, resulting in a geometry inversion!

---

Example using PyVista

import numpy as np
import pyvista as pv
pv.set_jupyter_backend('client')

dim = np.array([5,2,3])                             # x, y, z
ids = np.arange(dim.prod()).reshape(dim,order='F')  # with order='F', ids[:,0,0] == array([0, 1, 2, 3, 4])
msh = pv.ImageData(dimensions=dim+1)                # 'dimensions' is number of points = number of cells+1
msh['id'] = ids.flatten('F')                        # pyvista expects "x" as fastest index and "z" as slowest
msh.plot()

[eisenlohr]

Another way to look at this is to realize that:

>>> (grid_damask.material.flatten('F')[:128] == grid_damask.material[:,0,0]).all()
True
>>> (grid_damask.material.flatten('C')[:128] == grid_damask.material[0,0,:]).all()
True

[MarDiehl]

To explain the original observation: If “feature_Ids" is not given in the load_DREAM3D call, the grains identified by DREAM.3D through segmentation are not considered but cell-wise data is used, i.e. each cell is essentially its own “grain”. Nevertheless, to keep the material configuration files small, load_DREAM3D lumps any cells that have exactly the same orientation and phase into separate groups that then form a grain each. For synthetic data without any in-grain scatter, this strategy results in more or less the same number of materials (grain IDs) as when using the data from a proper DREAM3D segmentation.

@hugy888: Please mark this answer as solved if you have no further questions