The conventional cell is used to obtain higher order force constants

[ZhunyunTang]

Dear Dr. Tadano,

When I use a supercell based on the conventional cell for force constant calculations, I encounter the following problem.
My aim is to investigate the thermal transport properties along the direction of the basis vectors corresponding to conventional cell. I obtained higher order force constants using compressive sensing techniques ( a conventional cell with cubic structure is used). However, the program always seems to enforce the conversion of the force constant file to the format corresponding to the primitive cell ( rhombohedral structure). In other words, I'd like to get but can't get a file of force constants that contains conventional cell information. Can you give me some suggestions?

Best regards,
Zhunyun

[ttadano]

Hi,

Using a non-primitive lattice, such as a conventinal cell, in the anphon code is not supported in the current version of alamode. It will be available in the next major update 2.x.

However, using a non-primitive lattice will greatly increases the computational costs for thermal conductivity calculations as it scales as $N_s^3 N_k^2$, where $N_s$ is the number of atoms in the lattice and $N_k$ is the number of $k$ points.

If you want to obtain the thermal conductivity components along some crystallographic directions, other than the Cartesian XYZ axis, I recommend that you compute $\kappa_{\alpha\beta}$ using the primitive cell and then convert the basis of the obtained $\kappa_{\alpha\beta}$ values accordingly.

[ZhunyunTang]

Dear Dr. Tadano,

As mentioned in the previous question, could you please let me know if support for calculating force constants using a conventional cell (non‑primitive lattice) has been added in any recent version? If not, do you have a planned release date for version 2.x? If this functionality could be developed, we would be able to study the lattice dynamical properties along different crystallographic directions more freely.

Best regards,
Zhunyun

[ZhunyunTang]

Hi,

When I use compressive sensing technique to extract higher order force constants (based on primitive lattice), the program always displays an error. The error is reported as shown below (first illustration). I would like to ask you if this is due to memory reasons. However, in the case of my previous calculations, the number of force constants was larger than the current calculation (the second illustration is the output of the current calculation), but the program still works fine. This is very confusing to me.

Best regards,

[ttadano]

Thank you.

In your particular case, using FCSYM_BASIS=C was more efficient and robust. When FCSYM_BASIS=L, some extra contraints due to symmetry need to be considered, and this numerical process is rather sensitive to the numerical noise. That is probably the reason for the exception.

Anyway, please try with FCSYM_BASIS=C.

[ZhunyunTang]

Thank you very much, when using FCSYM_BASIS=C the number of inequivalent constraints is much reduced and the program runs well.

[Lamed-git]

Hi，
I also encountered the same error, no matter I set FCSYM_BASIS=C or L, this error will occur, the system is hexagonal crystal system. Do you have any suggestions?

[ttadano]

For the hexagonal systems, I recommend FCSYM_BASIS = L. Also, please symmetrize the input cell parameters and positions as much as possible (e.g., write sqrt(3)/2 up to 15 decimal points).

[Lamed-git]

I checked the input file and the output file, found that ALM correctly recognized the symmetry but still could not continue to function properly, I posted my input file to better illustrate my problem (leaving out specific elements and some coordinates)：
&general
PREFIX = Bi
MODE = optimize
NAT = 108; NKD = 2
KD =
NMAXSAVE = 3
FCSYM_BASIS = L
/

&interaction
NORDER = 5
NBODY = 2 3 4 2 2
/

&cell
1.8897 # factor in Bohr unit
12.6132647534550308 -0.0000000000012354 0.0000000000000024
-6.3066323768804908 10.9234077013903210 -0.0000000000000006
0.0000000000000025 -0.0000000000000003 22.7337435451557539
/

&optimize
LMODEL= adaptive-lasso
DFSET=DFSET_merged

CV = 0
L1_RATIO = 1.0
L1_ALPHA = 0.0

STANDARDIZE = 0
CONV_TOL = 1.0e-8
/

&cutoff
- None 12.7844 10.0148 7.5588 7.5588
/

&position
1 0.0000000000000000 0.0000000000000000 0.1216590932179206
1 0.3333333333333333 0.0000000000000000 0.1216590932179206
1 0.6666666666666666 0.0000000000000000 0.1216590932179206
1 0.0000000000000000 0.3333333333333333 0.1216590932179206
...
/

The output file terminates as follows：
ICONST >= 10 : Constraints will be considered algebraically.

Number of free HARMONIC FCs : 570
Number of free ANHARM3 FCs : 4061
Number of free ANHARM4 FCs : 7132
Number of free ANHARM5 FCs : 84
Number of free ANHARM6 FCs : 112

Time Elapsed: 5213.61 sec.

---

OPTIMIZATION

LMODEL = adaptive-lasso

Training data file (DFSET) : DFSET_merged

NSTART = 1; NEND = 199
199 entries will be used for training.

Total Number of Parameters : 53738
Total Number of Free Parameters : 11959
terminate called after throwing an instance of 'boost::wrapexceptstd::out_of_range'
what(): bimap<>: invalid key

I think the program spends too much time generating constraints from crystal symmetry, but I'm not sure what the possible cause of this problem is. Any suggestions?

[ZhunyunTang]

Hi,
When I use a supercell containing 512 atoms to fit higher order force constants and output fourth order force constants in shengbte format, the following error is reported. Does this phenomenon stem from having too many force constants to store? In addition, I would like to ask you if there is a way to solve this problem?

_**_Force constants in a human-readable format : Zr-anhar.fcs
Input data for the phonon code ANPHON : Zr-anhar.xml
Third-order FCs in ShengBTE format : Zr-anhar.FORCE_CONSTANT_3RD
Caught an exception when trying to allocate 4-dimensional array
std::bad_alloc : Array shape = 24x1536x1536x1536
std::bad_alloc : Array size (MB) = 695784

Best regards,
Zhunyun

[ttadano]

I have created #213 to keep track this issue.

[ZhunyunTang]

Thank you. In the current version, is there a corresponding keyword to specify the sparse datatype?

[ttadano]

Unfortunately, we still haven't implemented it. If possible, please use a large memory node that has more than 700 GB for the moment.

[ttadano]

I have changed the code to use a sparse data type and pushed it to develop.

This version hopefully solves the issue.

[ZhunyunTang]

Great. The modified code successfully solved the issue.