-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stress/Strain elastic constants testing and validation #194
Comments
While this is fresh in my mind after a chat with @AxelHenningsson and @jonwright today:
# Take the B0 of the cell
C_c = np.linalg.inv(B0).T
E = np.column_stack((C_c[:, 0], np.cross(C_c[:, 2], C_c[:, 0]), C_c[:, 2]))
E /= np.linalg.norm(E, axis=0)
strain_crystal_tensor_IEEE = E.T @ ( strain_crystal_tensor_imaged11 ) @ E
|
The materials project api is giving me back two elastic tensors, one "raw" and one "ieee_format". Also a set of lattice vectors in the structure field (with a surprising selection of axes). The code above looks like it does not work for monoclinic or triclinic? C_c look like they are meant to be the a,b,c real space vectors, then it is forming x||a, z||c and making a right-handed set with axc || b* along y. The matrix E is not a rotation unless a and c are at right angles. I suspect we need something like: z || c so:
... but it all depends on what the IEEE people have defined in their top-secret document. I have a vague feeling we would be better off just defining the IEEE reference lattice when computing strains. For example:
Like this, the strains ought to be with respect to the IEEE reference state (or we have to go back to debugging that finite strain code again). It was meant to be set up to let you input the reference as a vector lattice. |
It seems the IEEE rules are defined here: https://github.com/materialsproject/pymatgen/blob/77195153effda5dc97e28a47507ab64a52246ffb/src/pymatgen/core/tensors.py#L406 To use the IEEE reference lattice when computing strains, wouldn't we have to rotate the |
It seems that elastic constants need to come with a reference "lattice" setting. I wonder if it makes more sense to add a property to unitcell that gives back unitcell.IEEE for a reference lattice in the IEEE convention. This leaves it open to add some other convention when it comes up, and lets you raise an error for unit cells that need a transformation (primitive to rhombohedral, or a,b,c not in the right order, etc). Several important unit cell settings that are allowed by ImageD11 are not permitted by IEEE, so we would have to transform the UBI to the new setting as well. For the case of quartz, the problem seems to be the sign of C14. Materials project has both mp-6390 and mp-7000, and they have opposite signs for C14. To get this right, we need to compute the structure factors using the two crystal structures that are in materials project and cross-check with their atom co-ordinates. The quartz lattice has a 6-fold axis along c, but the structure only has a 3-fold. The IEEE rotation they are returning looks like a 6 fold, so they are flipping the sign of their C14. The scatter on the numbers (raw vs IEEE and mp-6930 vs mp-7000) suggests there is some other difference or problem. But I don't think you can compute stresses for quartz unless you have checked the intensity of (101) vs (011), etc, and picked the orientation with an extra indexing step that uses intensities. Demo code to get data from materials project is below. Something I don't understand is that the unit cell is completely wrong (5.1 vs 4.9 for a). Anyway, the "lattice" matrix they return looks like the same one as ImageD11, but they are choosing a [110] direction. So their "raw" setting looks like the one from Busing and Levy, but with a 3-fold axis applied.
and output:
|
Moving the discussion in merged pull #192 into a new issue. The problem is which numerical values to input for the numbers in the calculations of stress from strain, and whether the numbers can be checked.
Some unit tests could be added.
we do not have the old FitAllB strain convention in ImageD11 yet. This could be added for checking against fitallb.
Then for trigonal quartz as a low symmetry example. We had an indexing ambiguity, the (100) direction is not distinguished from the (110) direction until you look at the peak intensities. For high-temperature beta quartz, the structure is hexagonal. For stresses in alpha quartz, it seems to come down to the sign of C14, which goes to zero when the structure goes from trigonal to hexagonal (Ohno, I., Harada, K. & Yoshitomi, C. Temperature variation of elastic constants of quartz across the α - β transition. Phys Chem Minerals 33, 1–9 (2006). https://doi.org/10.1007/s00269-005-0008-3). For crystals that are twinned, this might not matter.
There is a description of the problem of conventions here:
https://www.comsol.com/blogs/piezoelectric-materials-understanding-standards/
In the case of quartz, the C14 parameter appears to change sign when going from the IRE 1949 convention to the one from IEEE 1978. Some intensity ratios are discussed here:
https://royalsocietypublishing.org/doi/pdf/10.1098/rspa.1926.0025
... and their relation to macroscopic crystal axes is here:
http://www.minsocam.org/ammin/AM30/AM30_326.pdf
... and here, BSTJ 22: 3. October 1943: Use of X-Rays for Determining the Orientation of Quartz Crystals. Bond, W.L.; Armstrong, E.J.:
https://archive.org/details/bstj22-3-293
Somehow we need to summarise all that literature into something that matches a set of elastic constants to a crystal structure that gives the diffracted intensities. Maybe taking the numbers from the materials project is unambiguous, as they are providing both together:
https://next-gen.materialsproject.org/materials/mp-7000?crystal_system=Trigonal&formula=SiO2
The text was updated successfully, but these errors were encountered: