ABINIT Discussion Forums

Hi, can someone shed light on the use symmetry in the rfstrs (strain) DFPT calculation? My example is aluminum--an FCC cell, only 1 atom in the primitive cell. Questions arising:

1) The code with rfstrs 3 runs all 6 strain calculations, though by symmetry for this crystal I would think fewer would be needed (for example, in the rfelfd case on an FCC crystal, such as NaCl, only one direction is calculated even with rfdir 1 1 1, with the other two reconstructed by symmetry). Why is symmetry over ipert not used in this case?

2) For the 6 calculations, the first 3 should give the same energy (longitudinal strain) while the second three should also give the same energy (shear strain). But they only do to about 6 digits of precision. I've tried hard to converge better, including a very dense kpt set, empty bands, and so forth. What this leads to is that the ultimate elastic tensor computed by anaddb is almost but not quite as symmetric as it should be--some elements that should be equal are equal only to a part in 10^6, likewise elements that should be identically zero are close to zero but not at machine precision. Why would these energies differ to this level?

3) Following question 2, it would appear that the final elastic tensor is not symmetrized according to the space group in use. Why is that? (can't be done, or hasn't been done, or shouldn't be done, or something else?)

thanks,
Joe

In addition I find that the symmetry breaking is quite dependent on the primitive unit cell orientation choice. For example, if I use the abinit conventional FCC construction using acell and rprim of 0 1/2 1/2, 1/2 0 1/2, 1/2 1/2 0, I get a small amount of symmetry breaking as noted before. But if I use acell and angdeg 3*60, the longitudinal symmetry breaking is about 1 part in 1000, which is quite a lot. In both cases the symmetry finder correctly identifies an fcc cell.

Joe

OK, after much work, I think I understand what abinit is doing.

a) there is no symmetry breaking in the strain code. The elastic tensor that comes out is symmetry-correct (I checked this carefully by writing python code that did a full symmetry projection of the elastic tensor using all the space group operators).

b) What does happen is that if your input rprim's are not aligned nicely with a "laboratory" frame, then the resulting elastic tensor will not look like the text book examples. Thus for instance: consider a simple orthorhombic case. If your rprim's are (1,0,0), (0,1,0), (0,0,1), then your crystal frame is aligned nicely with respect to an imaginary lab frame, and if you measured the elastic tensor elements, your measurements would align with the crystal axes and you would get the standard elastic tensor pattern for an orthorhombic crystal. However, if you chose to describe your crystal with rprim = (1/sqrt(2),1/sqrt(2),0); (-1/sqrt(2),1/sqrt(2),0),(0,0,1), then your elastic tensor would "look" strange, but still be correct, because your crystal axes do not line up nicely with a lab frame. It is not wrong to do this, as long as you interpret the elastic tensor appropriately. I checked this by computing the elastic tensor with a simple alignment, and in a non-standard alignment, and then rotating the non-standard tensor back to the standard alignment by hand (well, by Python).

c) It is "safest" to align rprim as outlined in for example Bradley and Cracknell for each crystal class, before running abinit. Abinit will give the correct answer in all cases regardless, but by pre-aligning the rprim's, the answers will be easiest to interpret.

d) I am considering cleaning up the anaddb output to take the above into account, but am not sure it's worth the effort. Have to think about this (this would require determining the crystal class from rprim, checking whether the input rprim followed the conventional alignment, determining the necessary rotation operator if not, and applying this operator to the elastic tensor computed in anaddb).

If anyone reads the stuff I post here, thanks!

Joe

Hi Joe,

Sounds like you have sorted things out in principle at least. It is a bit disappointing that we only get 5-6 digits, but perhaps that's inevitable for delicate calculations like elastic constants. We should be able to symmetrize them after the fact, though, and impose all digits being equal, shouldn't we?

For the alignment in the anaddb output, it will not be too hard - the spgroup and class are already available inside abinit subroutines. Hard coding the Cracknell will be the longer part - how many of these are there? Also, for the output, I would be careful to be very explicit and tell the user that the axes have been realigned - if they expect something from their orientation, or are making a supercell on purpose whose axes are rotated they will not understand the output, and may mix up c11 c12 and more which become linear combinations of what they expect...

If you want to discuss the equations or choices I am here (or wherever)

Best

Matthieu

Hi,

yes, I think in anaddb the elastic tensors could be symmetrized pretty easily, that would clean the output (but it would still "look" non-standard if the cell was not aligned in a nice way).

As for cell alignment, there are (I think) just the 14 crystal classes to consider. I've been back and forth on this one, and came to the conclusion that it's probably not worth the effort to code into anaddb. Those who know well should quickly understand the issue (well, I guess I should have known well but it took me a bunch of work to explain it to myself). What I have done is added an explanatory comment to the elastic tutorial, detailing how and why this behavior happens. To be honest, at this point, given all the other things I have to do, and the fact that the output of abinit is correct (but you do have to understand it properly, as usual) I wouldn't want to invest time into this. Symmetrizing the tensor output would be less work though and that might be worth doing.

Joe