I suspect there might be an issue with how hiphive handles ShengBTE’s FORCE_CONSTANTS_3RD files.
This started when I noticed significant discrepancies between the results from phono3py and ShengBTE using the same set of force constants, which made me question whether the conversion from fc3.hdf5 to FORCE_CONSTANTS_3RD was working correctly.
To test this, I wrote a simple script:
from hiphive import ForceConstants
from ase.io.espresso import read_espresso_in
prim = read_espresso_in('prim.in')
supercell = read_espresso_in('super.in')
fcs = ForceConstants.read_shengBTE(supercell, 'FORCE_CONSTANTS_3RD', prim, 1e-8)
fcs.write_to_shengBTE('FORCECONSTANTS_3rd1', prim)
fcs = ForceConstants.read_shengBTE(supercell, 'FORCECONSTANTS_3rd1', prim, 1e-8)
The script fails during the second call to read_shengBTE with the following error:
File "/home/gregory/.local/lib/python3.10/site-packages/hiphive/input_output/shengBTE.py", line 248, in _sheng_to_fcs
raise Exception('Ambiguous force constant.'
Exception: Ambiguous force constant. Supercell is too small
Additionally, I noticed a difference in the number of blocks:
- The original
FORCE_CONSTANTS_3RD file has 1521 blocks (the first number in the file)
- The new
FORCECONSTANTS_3rd1 file only has 606 blocks
Am I possibly doing something wrong, or could this indicate a genuine issue with hiphive?
I’d appreciate any insights or suggestions on this matter.
Bugs are always possible ^^ can you double check that you are using consistent prim and supercells (the permutation of the force constants/supercell typically messes up things during conversions)? Does it also fail when doing the conversion using force constants from a pure hiphive calculation?
Yes, I’m confident I’m using consistent primitive and supercells.
Regarding the conversion from a pure hiPhive calculation: I can’t verify it quickly. The conversion itself runs without visible errors, but validating its correctness is difficult. An indirect check would be to compare results from Phoebe using the fc3.hdf5 file and the FORCE_CONSTANTS_3RD file, but that’s a rather lengthy process.
Given that, I think the most productive first step is to focus on the clear bug in the read_shengBTE → write_to_shengBTE → read_shengBTE chain. This workflow is definitely failing, and it’s a more contained problem to start with.
I tested the conversion chain using two different sources for the ForceConstants:
ForceConstants from a pure hiPhive calculation: In this case, everything works perfectly. The chain write_to_shengBTE → read_shengBTE → write_to_shengBTE → read_shengBTE completes without any errors. The generated FORCE_CONSTANTS_3RD files are identical at each step.
ForceConstants loaded from files created by other codes (phono3py/ShengBTE): Here, the original problem persists. The chain read_shengBTE (from the external file) → write_to_shengBTE → read_shengBTE (from the new file) fails with the same “Ambiguous force constant. Supercell is too small” error I described initially.
The issue seems to be specific to the import (read_shengBTE) of FORCE_CONSTANTS_3RD/fc3.hdf5 files that were not generated by hiPhive itself. This points to a potential discrepancy in how hiPhive interprets the format or the data structure of force constant files from phono3py/ShengBTE compared to the files it generates.
Perhaps there are subtle differences in how the primitive cell mapping is handled or how the atoms in the supercell are ordered when these files are written by the different programs.
It would be great if the developers or anyone else in the community could look into this import issue. I am happy to provide the example FORCE_CONSTANTS_3RD files from phono3py that trigger the error if it helps with debugging.
Thanks for your efforts 
it would be great if you could open an issue at the gitlab repo and append the scripts.
The ambiguous force constants I think is from hiphive not liking to project the force constants on a too small supercell. So that should go away if you just repeat the supercell twice I think.