Inconsistent treatment of strain throughout the code

[yuzie007]

First of all, thank you so much @jochym for sharing your Elastic code with the community.

Here I would like to report my concern about the convention of strain in the code.

To my best knowledge, in the common definition of the Voigt notation for strain, the strain values $\epsilon_1, \cdots, \epsilon_6$ are related to the tensor components as follows,

$$ \begin{pmatrix} \epsilon_{11} & \epsilon_{12} & \epsilon_{13} \\ \epsilon_{21} & \epsilon_{22} & \epsilon_{23} \\ \epsilon_{31} & \epsilon_{32} & \epsilon_{33} \end{pmatrix} = \begin{pmatrix} \epsilon_{1} & \epsilon_{6} / 2 & \epsilon_{5} / 2 \\ \epsilon_{6} / 2 & \epsilon_{2} & \epsilon_{4} / 2 \\ \epsilon_{5} / 2 & \epsilon_{4} / 2 & \epsilon_{3} \end{pmatrix}, $$

i.e., $\epsilon_4 = 2 \epsilon_{23}$, where we have the coefficient 2.
This is different from the convention for the stress (without the coefficient 2).
Formally, the shear components in the Voigt notation are equal to “engineering” shear strains.
At least in the context of elastic properties, the Voigt notation is not just replacements of indices.
And, the common stress-strain relation like (for cubic):

$$ \begin{align} \begin{pmatrix} \sigma_{1} \\ \sigma_{2} \\ \sigma_{3} \\ \sigma_{4} \\ \sigma_{5} \\ \sigma_{6} \\ \end{pmatrix} &= \begin{pmatrix} B_{11} & B_{12} & B_{12} & 0 & 0 & 0 \\ B_{12} & B_{11} & B_{12} & 0 & 0 & 0 \\ B_{12} & B_{12} & B_{11} & 0 & 0 & 0 \\ 0 & 0 & 0 & B_{44} & 0 & 0 \\ 0 & 0 & 0 & 0 & B_{44} & 0 \\ 0 & 0 & 0 & 0 & 0 & B_{44} \\ \end{pmatrix} \begin{pmatrix} \epsilon_{1} \\ \epsilon_{2} \\ \epsilon_{3} \\ \epsilon_{4} \\ \epsilon_{5} \\ \epsilon_{6} \\ \end{pmatrix} \end{align} $$

is written using the above common Voigt notation.
I confirmed these points with several textbooks (Nye and Grimvall).

My concern is that the strain treatment is not well consistent through the code. Specifically,

• get_strain: It returns stress, not in the common Voigt notation, but actually just as an array of tensor components.
• regular, hexagonal, …: They must take the tensor-component strains rather than those in the Voigt notation.
• get_cart_deformed_cell (and thus get_elementary_deformations): here, the shear strains are engineering strains and thus the strain must be given in the Voigt notation.
• The $s$ in the document are not in the Voigt notation but in just tensor components. The least-square stress-strain relation in the document is also given, not for the common Voigt notation, but for the array of tensor components.

Particularly for the non-Voigt convention of get_strain may cause confusion for readers in realistic cases:

• If users see an 6-component array returned, they would naturally believe this is given in the Voigt notation, while presently this is not true.
• Further, if users would like to check the correctness of their obtained elastic constants via the "one-axis" approach (described in the last of this page), they may get twice larger values for shear elastic constants due to the usage of non-Voigt strain in get_strain.

To demonstrate the issue, I made a test using ASE EMT potential Cu_EMT.zip:

• In jochym0 I used get_elementary_deformations and get_elastic_tensor and obtained C11 = 172 GPa, C12 = 116 GPa, C44 = 90 GPa
• In jochym1 I used the one-axis approach using get_cart_deformed_cell and linear fitting and obtained C11 = 173 GPa, C12 = 115 GPa, C44 = 180 GPa, where C44 is twice larger obtained. This is because the strain is given not in the common Voigt notation.

To solve the issue, I wish to suggest:

• At least the get_strain method, the returned values should not be called “in the Voigt notation”.
• Ideally the get_strain method can be modified to return strain in the common Voigt notation. This also requires corresponding changes in other methods like regular, hexagonal, etc.

It would be very appreciated if you kindly think of these points above. Thank you so much for your help in advance.

[jochym]

@yuzie007 Thank you for pointing out potential problems. The stress notations are indeed confusing. I believe I have followed L&L conventions. Nevertheless, I will review your comments and also your proposed modifications. I will get back to you.

[yuzie007]

Thank you very much @jochym for your prompt and kind response! It would be very helpful if you cross-check.

[jochym]

@yuzie007 It seems you are right regarding the inconsistency of the code vs. textbook definition of the Voight notation. I still believe I have followed L&L conventions (except for errors ;), but they are indeed confusing. I think the code is internally consistent, but should be corrected to follow textbook definitions. My proposal is as follows: I will update the build/publishing system to follow modern standards. Then, as a first new release, I will publish the fixed code (tetragonal and hexagonal coeff.). Then, I will work on changing the convention to the new one. If you would like to help with this, I will naturally be happy to accept pull requests or any other input.

[yuzie007]

Thank you so much @jochym for the kind and careful review. I agree on the procedure you suggested. It would be really helpful for myself as well as any other users if Elastic has a new release with fixed hexagonal and tetragonal coefficients as well as new conventions. I would be very happy if I can help something for new releases. I actually have a few things in mind, but before opening issues I would like to check by myself.