Frequently asked questions

Here are answers to some frequently asked questions. Feel free to also read through previously asked questions by users on matsci.org and in the gitlab issue tracker.

Failing tests

When starting to use hiphive it is a good idea to run all the tests to check that everything works as expected. A few common reasons why tests may fail include

Out of sync test and source-code. The tests have to match the version of the package.
Old packages: If the numpy/sympy/spglib version that has been installed does not match the version requirements some tests can fail.
Running hiphive on windows is currently not supported and if attempted strange errors and test failures can occur.

How should I select cutoffs for the ClusterSpace?

When selecting cutoffs for your model is often a good idea to try out a few different choices and see if you can achieve convergence. The easiest way to do this is to study the cross validation score as a function of the cutoffs. This will help you choose optimal cutoffs and allow you to detect potential overfitting.

Often it is also possible (and advisable) to study directly the convergence of the thermodynamic property of interest, e.g., the frequency spectrum or thermal conductivity, as a function of the cutoffs in order to ensure the results are converged.

How many training structures are required?

The number of training structures needed to train an accurate force constant potential strongly depends on the number of free paramreters (and hence crystal symmetry), the order of the expansion and desired accuracy.

The ClusterSpace you are working with contains the number of degrees of freedom of the force constant potential (accessible via cs.n_dofs). This will correspond to the number of columns in the sensing matrix when optimizing the parameters. Each training structure contains \(3N\) force components, i.e. each structure gives rise to \(3N\) rows in the sensing matrix. In general it is a good idea for the linear problem to be solved to be overdetermined, i.e. that the sensing matrix should contain more rows than columns. This will provide an initial indication of the number of training structures required.

Furthermore, it is a good idea to check the convergence of the force constant potential with respect to the number of training structures used. For example the RMSE score from the cross validation analysis, as done in learning curve topic, provides a good means to check convergence.

Optimizer fails with memory error

When running on multi-core systems you might encounter errors such as ‘RFE fails with “OSError: [Errno 12] Cannot allocate memory’. This can occur since scikit-learn, which is used for the optimization, attempts by default to parallelize the computation over multiple CPUs, increasing the memory requirement as well. This behaviour can be controlled via the n_jobs parameter. The default value (n_jobs=-1) attempts to use all available CPUs. To reduce the memory consumption the maximum number of concurrently running jobs should be set explicitly, e.g., n_jobs=2.

How do I enforce rotational sum rules for force constants calculated with phonopy

Enforcing rotational sum rules for force constants calculated with phonopy is possible with hiphive, but it requires several steps.

First, the phonopy-FCS must be converted to a ForceConstantPotential. This may introduce small errors in the force constant, as discussed in here.

Next, the rotational sum rules are enforced as described here. Here, one must use the post-processing approach, and it might be necessary to try a few different values for \(\alpha\) to correctly enforce the rotational sum rules. This approach generally works fine, but in our experience the best approach for enforcing rotational sum rules is to include the rotational constraints when fitting the force constants. However, this is not possible when using force constants from e.g. phonopy.

We recommend that you compare the dispersion between the original force constants, the ones produced by hiphive, and the ones produced by hiphive after enforcing the rotational sum rules. If the first two look the same, then the conversion of the force-constants to a ForceConstantPotential likely worked correctly.

The code below can serve as a template and starting point when enforcing rotational sum rules for force constants calculated with phonopy.:

from ase.io import read
from hiphive import ClusterSpace, ForceConstantPotential, enforce_rotational_sum_rules
from hiphive.cutoffs import estimate_maximum_cutoff
from hiphive.utilities import extract_parameters

prim = read('POSCAR')
supercell = read('SPOSCAR')

# Define a cluster space using the largest cutoff you can
max_cutoff = estimate_maximum_cutoff(supercell) - 0.01
cutoffs = [max_cutoff]  # only second order needed
cs = ClusterSpace(prim, cutoffs)

# import the phonopy force constants using the correct supercell also provided by phonopy
fcs = ForceConstants.read_phonopy(supercell, 'fc2.hdf5')

# Find the parameters that best fits the force constants given you cluster space
parameters = extract_parameters(fcs, cs)

# Enforce the rotational sum rules
parameters_rot = enforce_rotational_sum_rules(cs, parameters, ['Huang', 'Born-Huang'])

# use the new parameters to make a fcp and then create the force constants and write to a phonopy file
fcp = ForceConstantPotential(cs, parameters_rot)
fcs = fcp.get_force_constants(supercell)
fcs.write_to_phonopy('fc2_rotinv.hdf5', format='hdf5')

If you’re unsure about any line try the search function in the documentation. Relevant pages include:

ValueError when constructing ClusterSpace

If you get a value error like ValueError: (2, 417) is not in list when trying to construt a ClusterSpace it could be due to poor tolerance/precision of the input structure. If this is the case it can usually be solved by

atoms.set_scaled_positions(atoms.get_scaled_positions().round(6)%1)
ClusterSpace(atoms, ...)