Problem about correcting force constant after SCPH calculation using ALAMODE 1.3.0

[XiangXing96]

Dear Dr. Tadano,

I use ALAMODE to calculate the 2nd(harmonic)-, 3rd- and 4th- order force constant with the force and trajectories from lammps and then conduct scph calculations. There are no warning appears during the whole process. However, when I use scph_dfc2 file to correct the 2nd-order force constant, warnings appear take place like
Warning: The following force constant doesn't exist in the original file:
-4 -4 -1 0 0 1 1 0.000684271
Warning: The following force constant doesn't exist in the original file:
-4 -4 -1 0 0 1 2 -0.000481604
Warning: The following force constant doesn't exist in the original file:
-4 -4 -1 0 1 1 0 0.000684271

Based on your previous suggestion for the problem, I check the numerical digits of lattice vectors and fractional coordinates as well as KMESH_INTERPOLATE. The numerical digits are 15 and the KMESH_INTERPOLATE is consistent with the supercell size. Additionally, when I conduct the whole calculation with 222 supercell, the problem do not take place.

Could you give me some suggestions about the problem? For convenience, I attach the harmonic force constant input (run.harm), high-order force constant input (run.high-order-fitting) and scph input (scph.in).

run.harm:

high-order force constant input:

scph.in:

[ttadano]

Hi,

All input files look good except for the numbers in the &position field like 0.124999999.

Could you round all of these numbers to a fraction, like 0.125, and see if the problem persists.

[XiangXing96]

Hi, Dr. Tadano,
I get it. Thanks very much for your helps.

[XiangXing96]

Hi, Dr. Tadano,
Sorry for bothering you again.
Recently, I check the case again but the warning still takes place even with FC_ZERO_THR=1.0e-15 (make.log). Therefore, I want to check the space group of structure recognized by alm and anphon. I find Space group information in the log file of alm, while that does not appear in the log file of anphon. Is there a way to find that? Additionally, I want to know whether the "Atomic positions in the primitive cell (fractional):" in the log file of anphon (scph.log) is the atomic position in reciprocal space. I find they are different from those listed in FC2XML, just like . Could you give me a favor? Finally, I want to use a finite cutoff for the harmonic force constant, which is the cutoff of the model potential. Will that make the warning more serious?
Thank you in advance.

[ttadano]

Recently, I check the case again but the warning still takes place even with FC_ZERO_THR=1.0e-15 (make.log).

Sorry, I forgot to comment out some debug print lines in the previous commit. The outputs shown in your make.log are not warning, so your calculation seems to have finished properly.

I find Space group information in the log file of alm, while that does not appear in the log file of anphon. Is there a way to find that?

The anphon code does not print the space group symbol. It just prints the number of space group (SG) operations.
If (# of SG operations in anphon) != (# of SG operations in alm) * (# of primitive cells in the supercell) does not hold, it indicates that anphon fails to detect the SG symmetry. If the above equation holds, the calculation should be OK.

Additionally, I want to know whether the "Atomic positions in the primitive cell (fractional):" in the log file of anphon (scph.log) is the atomic position in reciprocal space. I find they are different from those listed in FC2XML, just like . Could you give me a favor?

Yes, they are fractional coordinates of atoms in a primitive cell detected by anphon. Where did you see the difference?

Finally, I want to use a finite cutoff for the harmonic force constant, which is the cutoff of the model potential. Will that make the warning more serious?

I don't know it if it would be more serious or not. In general, if you see a warning, it means that the anharmonic correction to the 2nd-order IFCs has longer-range components than the original 2nd-order IFCs. This situation may be a little strange because the anharmonic interaction is usually more short-ranged than the harmonic interaction. My suggestion is to make KMESH_INTERPOLATE smaller until the warning disappears.

[XiangXing96]

Hi, Dr. Tadano,
Thanks for your reply.

For the first question:
In make.log, some elements in the last column are still pretty large and thus there seems still some problems in this calculation.

For the second question:
Based on your replies, I check the (# of SG operations in anphon) != (# of SG operations in alm) * (# of primitive cells in the supercell). In my calculation, # of SG operations in anphon, alm and # of primitive cells in the supercell are 4, 108 and 27. Additionally, I give a primitive cell into the anphon and alm and then output the symmetry information, respectively. I find that the symmetry information in alm.log is almost the same to that in the initial cif file, while that in anphon.log is different. Can the difference lead to the warning in make.log?
alm.log

anphon.log

For the third question:
Ok, I will have a try to decrease the KMESH_INTERPOLATE.

[ttadano]

For the first question:
In make.log, some elements in the last column are still pretty large and thus there seems still some problems in this calculation.

If you haven't pull the latest update on the develop branch, please do so. I think the warning messages will disappear with the new version.

Based on your replies, I check the (# of SG operations in anphon) != (# of SG operations in alm) * (# of primitive cells in the supercell). In my calculation, # of SG operations in anphon, alm and # of primitive cells in the supercell are 4, 108 and 27.

Do you mean (# of SG operations in anphon) = (# of SG operations in alm) * (# of primitive cells in the supercell)?

Additionally, I give a primitive cell into the anphon and alm and then output the symmetry information, respectively. I find that the symmetry information in alm.log is almost the same to that in the initial cif file, while that in anphon.log is different. Can the difference lead to the warning in make.log?

Maybe, that is not problematic because +0.5 and -0.5 are equivalent.