When performing the Raman on top of high-symmetry crystals (e.g. cubic MgO), the Raman tensor is fully 0 due to symmetry (this happening to centain classes of materials).

For this reason, when computing the Raman tensors in the compute_susceptibility_derivatives method, the code crashes since the array referring to the phonon eigenvectors is empty (this does not happen with the flag use_irreps = False).

Thus, we need to implement this case scenario.
A first simple solution would be recognising when the array of the eigenvectors is empty and send a warning message (saying e.g. "first-order Raman is zero"), while returning empty arrays.

When using get_builder_from_protocol, the threshold per atom in

scf:
  meta_parameters:
    conv_thr_per_atom: 1.0e-15

will be used referring to the unitcell, not the supercell. This is due to the fact that we use straight the method of PwBaseWorkChain. A rescale would be desirable, e.g. by using the determinant of the supercell matrix.

The linter pylint is very good thanks to its deep checks and for being quite strict. Nevertheless, it is rather slow, especially now that the project is starting to get larger and larger. Still, the time for running it is reasonable, but it should be considered whether to move to ruff, which is as precise as pylint, but way much faster.

When a finite electric field PwBaseWorkChain crashes, the DielectricWorkChain crashes with the following exception:

field_data = {str(i):wc.outputs.output_trajectory for i, wc in enumerate(workchains)}
  File "/aiida_vibroscopy/workflows/dielectric/base.py", line 591, in <dictcomp>
field_data = {str(i):wc.outputs.output_trajectory for i, wc in enumerate(workchains)}
  File "/aiida/orm/utils/managers.py", line 145, in __getattr__
    raise NotExistentAttributeError(
aiida.common.exceptions.NotExistentAttributeError: Node<93595> does not have an output with link label 'output_trajectory'

Expose kpoints inputs in WorkChains (e.g. DielectricWorkChain) to allow for a single evaluation of the create_kpoints_from_distance process. An implementation is provided, but without exposing the kpoints related inputs. Exposing such inputs would make more consistent and less code dramatic the outlines.

The module quadpy is no more open source. This makes the integration over sphere to crash.
We need a new implementation that accounts for some schemes.

The README and the docs are missing a guide for external contributions. This should include information about:

1. Code standards: pre-commit, (py)tests, code versioning, how to do a release
2. CLA (contribution license agreement - to set up automatically via GitHub for signing up etc)

Some pytests are missing. In particular:

• Tests for the NumericalDerivativesWorkChain.
• Tests for the numerical derivatives calcfunctions.
• Tests for the symmetries in the DielectricWorkChain; one can exploit real test case scenario using the protocol.
• More tests for the get_builder_from_protocol methods.
• Tests for the future kpoints exposure.
• Tests for the setup methods.

The PhononWorkChain can spawn quite a few parallel PwBaseWorkChain, especially in low-symmetry systems. It would be ideal to add the capability to submit only a certain maximum number of them at a time, until the workchain runs out of them.

In PhononWorkChain in the inspect_all_runs method there is a missing f-string specifier on line 454
that is causing the workchain to not report what the exit status for the subprocess that failed.
'with exit status {workchain.exit_status}' should be f'with exit status {workchain.exit_status}'

Keeping track of the changes among published versions of the code is extremely important and useful to the future users of the code. This will make it easier to e.g. spot bugs when something suspicious happens.

The aiida-quantumespresso now requests the SSSP PBEsol family v1.3. If one re-runs the docs (now deactivated), it will crash.

A minimal documentation must be provided to describe the main functionalities:

• What can the code do?
• Which workflow does what?
• How can one run a workflow for a specific scientific question/property?
• How can one post-process and access the data?

It would be really great if we can also compute the ionic contribution to the dielectric constant as done in VASP and Materials Project. Currently, we have only the so-called ion-clamped (or high-frequency) dielectric constant but sometime it is necessary to have the total dielectric constant for example when we want to compute the correction for defect formation energies in which we allow the defect position to relaxed. The calculations should be very fast as we already have all the ingredients namely the Born effective charges and the interatomic force constant.
The expression of this ionic contribution can be found in this slide (page 36)

Add support for finite electric fields properties, i.e. electric_field_offset. Rename consequently the variable electric_field in electric_field_step in the DielectricWorkChain for better clarify (change also the logic and add tests).

The warnings coming from the symmetrization of tensors is not reported. Report them using the self.report method, e.g. passing a log.

There is a typo in the overrides (advanced) section for the input yaml file.

The create_directional_kpoints method crashes when calling pymathen for molecules.
The relevant traceback:

    pymat = structure.get_pymatgen_structure()
  File "/home/bastonero/.conda/envs/aiida/lib/python3.8/site-packages/aiida/orm/nodes/data/structure.py", line 1292, in get_pymatgen_structure
    return self._get_object_pymatgen_structure(**kwargs)
  File "/home/bastonero/.conda/envs/aiida/lib/python3.8/site-packages/aiida/orm/nodes/data/structure.py", line 1838, in _get_object_pymatgen_structure
    raise ValueError('Periodic boundary conditions must apply in all three dimensions of real space')
ValueError: Periodic boundary conditions must apply in all three dimensions of real space

Per se this is not an issue as with molecules one is supposed to use only 1 kpoints. A possibility is to simply block the use of the kpoints_parallel_distance from the inputs for non periodic structures.

An other question is how to treat 1D and 2D materials. From the error, it seems pymatgen will complain. Since the projection onto crystal lattice is a very cheap operation, the call to pymatgen structure can be dropped and a custom solution implemented.

The function call:

    def run_intensities_averaged(self):
        """Run an `IntensitiesAverageWorkChain` with the calculated vibrational data."""
        self.ctx.intensities_average = AttributeDict({})
        for key, vibrational_data in self.ctx.vibrational_data.items():
            inputs = AttributeDict(self.exposed_inputs(IntensitiesAverageWorkChain, namespace='intensities_average'))
            inputs.vibrational_data = vibrational_data
            inputs.metadata.call_link_label = key

            future = self.submit(IntensitiesAverageWorkChain, **inputs)
            self.report(f'submitting `IntensitiesAverageWorkChain` <PK={future.pk}>.')
            self.to_context(**{f'intensities_average.{key}': future})

calls self.ctx.vibrational_data, which is not set anywhere. So it should be correct to just use self.outputs.vibrational_data.