hiphive issueshttps://gitlab.com/materials-modeling/hiphive/issues2019-05-22T10:01:31Zhttps://gitlab.com/materials-modeling/hiphive/issues/395Fix links in workflow figure2019-05-22T10:01:31ZPaul ErhartFix links in workflow figure# Description
Several links in the [workflow figure](https://hiphive.materialsmodeling.org/workflow.html) of the user guide are outdated and need to be corrected.
# Demo
* all links point to sensible locationshttps://gitlab.com/materials-modeling/hiphive/issues/390Update graphene rotational example2019-05-15T19:43:31ZErik FranssonUpdate graphene rotational exampleFrom [comment](https://gitlab.com/materials-modeling/hiphive/issues/387#note_169214735) we should update the grapene rotational example.https://gitlab.com/materials-modeling/hiphive/issues/389The big different phono dispersion between Hiphive and phonopy2019-05-13T19:49:16ZYuan YanThe big different phono dispersion between Hiphive and phonopyDear all:
I am trying to use Hiphive for phono dispersion. I used both Hiphive and phonopy. But the result is different a lot at acoustics branch.
This is dispersion I get from phonopy: [phonopy_band.pdf](/uploads/2dc4af556528f662aef211b50fbc054b/phonopy_band.pdf).
This is dispersion I get from Hiphive:[Hiphive_band.pdf](/uploads/468cc1071ba5f34eab700ccb1e0c6a6f/Hiphive_band.pdf)
I have tested cutoff, I choose cutoff is [6.0] from the range 4.0 - 9.0, and [6.0] looks the best. This is the code to get phono dispersion[calculation.py](/uploads/dc17ff3af178519fe4b718ae7a97a5cf/calculation.py). This is the ratted structure documents containing displacement and force[rattled_structures.extxyz](/uploads/edb867416cc942fe2655e08c49f245e1/rattled_structures.extxyz)
I am not sure what makes this difference happen. Is there anything wrong I made?
Details for Hiphive calculation:
Materials: monolayer Tl20
supercell_size : 6*6*1
DFT_method: VASP
cutoff :6.0
structure_number:20https://gitlab.com/materials-modeling/hiphive/issues/388add new fitting method (ADMM)2019-05-07T13:58:18ZMattias Ångqvistadd new fitting method (ADMM)As a user I would like many fitting methods
### Background
ADMM is fast, have no parameters to adjust and gives very sparse solutions
## Sub-tasks
DEMO
* [x] new fitting method added
* [x] unit testedhttps://gitlab.com/materials-modeling/hiphive/issues/382Add a FAQ to userguide2019-04-14T07:09:02ZErik FranssonAdd a FAQ to userguide@freeriks suggested to add a FAQ to the userguide.
Possible extension of this could be to add some tips and tricks when using hiphive.https://gitlab.com/materials-modeling/hiphive/issues/380Explore sympy version requirement2019-04-05T17:15:08ZErik FranssonExplore sympy version requirementRecently a user had issue with hiphive due to an older version of sympy.
Since we obviously have a version requirement on sympy (though we dont know which versions work) this should be added to setup.pyhttps://gitlab.com/materials-modeling/hiphive/issues/379Explore faster potential energy calculation2019-04-05T17:12:35ZErik FranssonExplore faster potential energy calculationAccording to fredrik its possible to make the energy calculation in the calculator a lot faster.
This should be tested, if it can be made a lot faster than it should be implemented in accordance with ase.https://gitlab.com/materials-modeling/hiphive/issues/377EXPLORE: Replace pickle with more stable format for read/write2019-04-03T20:43:16ZPaul ErhartEXPLORE: Replace pickle with more stable format for read/write## Description
In #361 we ran into problems due to danger of changes in other packages causing havoc in our read/write functionality.
We should therefore carefully consider where else this could become a problem and how to solve these issues before they raise their ugly heads.https://gitlab.com/materials-modeling/hiphive/issues/372Add read/write functions for optimizer2019-03-17T19:16:10ZPaul ErhartAdd read/write functions for optimizer# Description
During learning curve analysis it is rather common to store the results of an optimization (i.e. the `Optimizer` object).
While many of the key objects in hiphive (and icet) have read/write functionality, the `Optimizer` class does not.
As a result, one is forced to resort to pickle manuallt, which has various disadvantages.
Therefore, we should consider adding read/write methods (possibly internally based on pickle, although that would create potential problems between versions).https://gitlab.com/materials-modeling/hiphive/issues/371Review weekly tests2019-05-23T17:11:45ZPaul ErhartReview weekly tests# Description
The weekly tests ([run on schedule](https://gitlab.com/materials-modeling/hiphive/pipeline_schedules)) take more than one hour to run, see e.g., [here](https://gitlab.com/materials-modeling/hiphive/-/jobs/178136006).
We should therefore consider whether the run time for the scripts in [`examples`](examples) can be reduced.
These tests should also be reviewed with the objective to remove the `allow_fail: True` condition in the CI.
# Demo
* `allow_fail` condition removed from CI
* total run time reduced (below one hour if possible)0.5https://gitlab.com/materials-modeling/hiphive/issues/357More flexibility when handling constraints2019-03-15T09:25:53ZFredrik ErikssonMore flexibility when handling constraintsBased on issue #350
Optimally the translational and rotational constraints should be able to both supply a nullspace before fitting and be able to project solutions afterwards.
The constraints should be subdivided into orders when possible.
The constraint matrices should be accessible based on order in order to be fitted simultaneously.
The sensing matrix should be accessible order-wise as well as with and without constraints imposed already.
There should be a clear mapping between orbits, parameters, constrained parameters and orders.
Contact person: @freerikslong termhttps://gitlab.com/materials-modeling/hiphive/issues/348EXPLORE: Allow unsorted FCs to be used in ForceConstantCalculator2019-04-14T07:14:29ZPaul ErhartEXPLORE: Allow unsorted FCs to be used in ForceConstantCalculator## Description
The FC calculator used for MD simulations relies on the label symmetry of the FCs.
If the FCs are read in phono3py or shengBTE format from file this will in general not be the case.
Therefore, we should consider adding functionality for symmetrizing FCs.
## Additional tasks
* add test for FC-MD based on unsorted FCs
* increase test coverage of `force_constants.py` as unsorted FCs are being tested in this issue
## Demonstration
* old and new tests passhttps://gitlab.com/materials-modeling/hiphive/issues/333Create wrapper class for handling fit data normalization and constraints2019-04-12T13:22:36ZErik FranssonCreate wrapper class for handling fit data normalization and constraints# Description
Some optimization methods, specifically ARDR, perform much better if the fit data is normalized and centered prior to it being forwarded to the optimizer.
This is currently possible but is inconvenient.
For both applications in [icet](https://gitlab.com/materials-modeling/icet/issues/348) and [hiphive](#357), there is also a need to impose constraints.
Both of these situations can be handled via an intermediate class as suggested by @angqvist and @erikfransson.
# Background
## Current procedure
``` python
A, y = sc.get_fit_data(key='metal_spacing_01')
y_mean_01 = y.mean()
y -= y_mean_01
y_scale_01 = 1/y.std()
y *= y_scale_01
cve = CrossValidationEstimator((A, y))
cve.validate()
cve.train()
parameters = cve.parameters
parameters /= y_scale_01
parameters[0] += y_mean_01
ce = ClusterExpansion(cs, parameters)
```
## Suggested solution
Pass the fit data through a `FitDataTransformer` object/class.
### Normalize data
``` python
fdt = FitDataTransformer(sc.get_fit_data(key='metal_spacing_01'), normalize_target=True, ...)
cve = CrossValidationEstimator(fdt.get_fit_data())
cve.validate()
cve.train()
ce = ClusterExpansion(cs, fdt.transform_parameters(cve.parameters))
```
### Impose constraints
``` python
fdt = FitDataTransformer(sc.get_fit_data(key='metal_spacing_01'), normalize_target=True, ...)
fdt.add_constraint(constraint_matrix1, weight=100)
fdt.add_constraint(constraint_matrix2, analytical=True)
cve = CrossValidationEstimator(fdt.get_fit_data())
cve.validate()
cve.train()
ce = ClusterExpansion(cs, fdt.transform_parameters(cve.parameters))
```
# Demo
* `FitDataTransformer` class implemented for both normalization and constraints
* new code is fully tested and documented (docstrings)
* new code is type hinted (#362)
* new module integrated in user guide (under `doc/source/module_ref`)
* new tutorial section
2019/03/15 @erhart rewrote issue description after EXPLORE was resolvedhttps://gitlab.com/materials-modeling/hiphive/issues/323EXPLORE: Improve handling of errors due to maximum cutoff close to neighbor s...2019-04-01T12:49:16ZErik FranssonEXPLORE: Improve handling of errors due to maximum cutoff close to neighbor shell## Background
I have a lot of interface systems with different number of vacancies and different ordering.
When relaxing these structures the distribution of distances becomes almost continuous and hence I encounter the error "maximum cutoff is close to neighbor shell".
(This has been a minor issue for clathrates).
My solution has been to just hard code a few different cutoff that I know will work but now when doing many different vacancy orderings this becomes fairly annoying.
``` python
# old solution
if n_vac == 0:
cutoff = 5.04
elif n_vac == 3:
cutoff = 5.035
elif n_vac == 4:
cutoff = 5.04
elif n_vac == 8:
cutoff = 5.039
```
## Description
I think the exception is a good idea to have as it prevents strange behavior.
But it would be nice if we can come up for a solution to make my use-case work without too much hassle?
## Suggested solution
1. I do not like flooding `ClusterSpace` with different settings but I guess you could have something like
``` python
cs = ClusterSpace(atoms, cutoffs, ignore_neighborshell_error=True)
```
2. Make the current exception into a warning?
## Exception
```
241 msg = 'Maximum cutoff close to neighbor shell, change cutoff'
--> 242 raise Exception(msg)
243
244 msg = ' Found {} center atom{} with {} images totaling {} atoms'.format(
Exception: Maximum cutoff close to neighbor shell, change cutoff
```0.5https://gitlab.com/materials-modeling/hiphive/issues/322Is it possible to include Born effective charges when fitting the force const...2019-02-14T16:40:19ZFlorian Knoopflorian_knoop@gmx.deIs it possible to include Born effective charges when fitting the force constants?As the title says, at least I could not find an option to include them in the fit to correct for long-ranged Coulomb contributions to the forces. I'm mainly curious to hear if you have included them or plan to.
Cheershttps://gitlab.com/materials-modeling/hiphive/issues/316Memory usage of ForceConstantCalculator2019-02-14T15:59:38ZErik FranssonMemory usage of ForceConstantCalculator## Description
Memory usage seem to blow up when constructing a `ForceConstantCalculator`
Problem seem to be that the numpy array references are lost when casting the list of fc to numpy array, i.e. in here.
```
for d in [self.clusters,
self.force_constants,
self.atom_indices,
self.atom_positions,
self.atom_counts,
self.prefactors,
]:
for k, v in d.items():
d[k] = np.array(v)
```
cc @freerikslong termhttps://gitlab.com/materials-modeling/hiphive/issues/296Logging in self consistent phonons should be improved2019-03-13T22:57:04ZErik FranssonLogging in self consistent phonons should be improvedThis is a minor issue but at some point it would be nice if we found a reasonable solution to this.
When the self-consistent phonons run you're setting up structure containers and adding hundreds of structures in the main loop.
This would yields a huge wall of text but instead we added the following to the SCP module
```
# Make poor man shut up
set_config(level=40)
```
But this is not the perfect solution as this will silence the logger for the rest of the session as well as forcing the logging from the SCPH function to be done via prints.0.6https://gitlab.com/materials-modeling/hiphive/issues/293Use sparse force constants and exploit the label symmetries.2019-02-14T15:02:56ZFredrik ErikssonUse sparse force constants and exploit the label symmetries.Right now, calculating the contribution from a cluster to the total energy (or forces) takes roughly $`\mathcal{O}(n3^n)`$ flops where $`n`$ is the order. However, consider the cluster $`(iiii)`$. This cluster has only 15 independent components compared to 81 for a four body 4th order cluster $`ijkl`$. These internal symmetries are not exploited in the code at the moment (we do however use the fact that e.g. cluster $`(ijk)`$ is equivalent to $`(ikj)`$).
Example
-------
Since we are often interested in high order - low n-body interactions this would benefit both the MD and fit-matrix calculation as well as save a lot of memory. The difference is of course even larger for sixth order etc.
Consider the cluster $`iiiijjjj`$. It is a two body, 8th order interaction. The raw format would take around 50kB while the actual number of independent components is only 2kB _before_ any symmetry constraint. And as the computational work is roughly equivalent to the memory footprint I think this could increase the performance with about one to two orders of magnitude.
Note that the above is true for a P1 symmetry system and the benefit could be even greater for e.g. Titanium.
Implementation
--------------
Depending on the level of ambition some tricks can be used to speed up things. To me, they are all not trivial though. With the sparse format in place, changing the actual contraction function should be easy. For the simple $`(iii)`$ cluster the data would look like:
```
cluster = (i, i, i)
indices = [
[x, x, x],
[x, x, y],
[x, x, z],
[x, y, y],
[x, y, z],
[x, z, z],
[y, y, y],
[y, y, z],
[y, z, z],
[z, z, z],
]
multiplicities = [1, 3, 3, 3, 6, 3, 1, 3, 3, 1]
```
and the corresponding list of fcis
$` \text{fcis = [} \Phi^{xxx}, \Phi^{xxy}, ..., \Phi^{yzz}, \Phi^{zzz} \text{]}`$
and the contraction would be
```
E = 0
for multi_index, multiplicity, fci in zip(indices, multiplicities, fcis):
u = 1.0
for index, atom in zip(multi_index, cluster):
u *= displacements[atom, index]
E += fci * multiplicity * u
```
The force calculation is a bit more complicated depending on level of ambition but goes along the same idea.long termhttps://gitlab.com/materials-modeling/hiphive/issues/256Adding stablizing terms to the force constant model for MD/MC purposes2019-04-08T15:49:46ZErik FranssonAdding stablizing terms to the force constant model for MD/MC purposes## Description
The MD-simulations for systems like
* 4th order Clathrate 300K
* 6th order Ni100 surface 1000K
* 8th order BCC Ti 1000K
keep crashing due to the force constant model not being stable.
## Suggestions
This could probably be solved by simply adding one or a few extra parameters specifically for bonding purpose.
For example to the 4th order clathrate model we could add a weak 8th order bonding onsite term which doesn't affect the normal dynamics much but helps stabilize the system.
Possible solutions could be
* Add high order bonding onsite term (this would break the sum rules)
* Add strongly anharmonic pair potential, as suggested by Fei, which could be fitted together with the force constant model (This will not break the sum rules since a pair potential obey sum rules.)
## Notes
We should think about how to interface this with the core of hiphive. I think it would be wise to start with absolute minimum functionality which would have to be.
* Module for giving an atoms object produce a `fit_matrix` (which can be appended to the fc `fit_matrix`).
* Class for ASE calculator for this new pair potential
* Unless ASE already have it, basic class for making hybrid calculators.0.5