Hubbard: add useful utility functions
#996
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add the possibility of finding a shell radius defining a sphere which contains the first (intersites) neighbours. This is helpful when using the `hp.x` code and having a structure containing onsite Hubbard atoms with different number of neighbours.
The Hubbard parameters can now be initialized simply by perfoming a nearest neighbour analysis (pymatgen). Standardization of the lattice and the atomic positions can also be performed to have all the atoms within the unit cell (needed for the `pw.x` routine).
Pymatgen does not order the atoms by distance. There is not apparently any such option in the API. Folding is then now sepatated from standardization (the latter could produce larger structures).
bastonero
added
type/enhancement
priority/nice to have
topic/utilities
priority/important
and removed
priority/nice to have
labels
|
For the docs probably we just need to add |
The refolding wasn't folding numbers close numerically to 1, e.g. 0.99999999. To circumvent the issue, a threshold is set, and it is possible to control it via input. Also, now the inputs for nearest neighbours are not passed via kwargs, but via an explicit dictionary input, which is then given via kwargs to the NN class.
The url for pymatgen to generate interlinks across API packages is added.
|
@mbercx @t-reents @sphuber good to have your feedbacks here. Example of usage: from aiida.orm import *
from ase.io import read
from aiida_quantumespresso.utils.hubbard import initialize_hubbard_parameters
atoms = read('./input.pwi') # anything ASE can parse
s = StructureData(ase=atoms)
hs = initialize_hubbard_parameters( # returns an initialized HubbardStructureData using nearest neighbours analysis
structure=s,
pairs={
# onsite manifold, onsite value, intersite value, dict of intersites {kind name: manifold}
'Mn': ['3d', 4.5, 1.0e-5, {'O':'2p', 'S':'2p'}],
'Fe1': ['3d', 5.0, 1.0e-5, {'O1':'2p', 'S':'2p'}],
...
},
)Cristiano and myself used it for different calculations, and the logics seem now robust. Probably not the best input API for the initialization of Hubbard parameters, but it is the price to avoid reinventing other classes which makes even more complicated to use this method, which should be easy to use and should hide the underlying complexity of the HubbardStructureData. |
A set of methods are added to account for some useful use-cases where the number of nearest-neighbours are needed or when only the set of indices and the translation vector are required (the latter is useful for parsing the Hubbard parameters computed from first-principles).
The `PhBaseWorkChain.get_builder_from_protocol` was untested. Tests are added, and the `electronic_type` input is added to allow for the computation of the dielectric and effective charge tensors when an insulator is in input. This is useful in other workchains, so that the `electronic_type` input can be passed seamlessly as a kwargs input at an higher level.
Fixes aiidateam#966 All the base workchains missed to override the `max_iterations` input. This is now fixed for all of them.
This adds support for Python 3.12.
…ance` Allow the user to specify the density of the q-point mesh using a new `qpoint_distance` input on the `PhBaseWorkchain`. The `qpoints` input of the wrapper `PhCalculation` is also moved replicate the usage of the `PwBaseWorkChain` for specifying Brillouin zone sampling. The `set_qpoints` step is added to the outline, where either: 1. the provided `qpoints` are directly passed to the inputs 2. the structure is retrieved via the `creator` of the `parent_folder` input, and subsequently used in combination with the `qpoints_distance` to generate the q-points mesh. A validator and basic protocol is added, along with the `qpoints_force_parity` input, which can be used to guarantee that the q-point mesh has an even number along any periodic direction of the lattice.
When using constrained magnetization via the `SYSTEM.tot_magnetization` input of `pw.x`, the calculation outputs two different fermi levels for the two spin channels: `fermi_energy_up` and `fermi_energy_down`. In this case the `PdosWorkChain` would except since it extracts the `fermi_energy` output in the `inspect_nscf` step of the outline. Here the step will check if the `fermi_energy` value is in the output, and look for the two values of the up/down spin channels in case it isn't. The fermi level of the NSCF step is then set to the maximum of the two levels. The `fixture_code` fixture is updated to use a query instead of `load_code`, since using `pymark.parametrize` with the hierarchy of fixtures can apparently create multiple instances of codes with the same label in the testing profile. Co-authored-by: Marnik Bercx <mbercx@gmail.com>
Switch to SSSP v1.3 in the `PwBaseWorkChain` protocols. Update the documentation to match. As support for SSSP v1.3 was only added in `aiida-pseudo==1.1.0`, we bump the dependency to `~=1.1` as well. Co-authored-by: Marnik Bercx <mbercx@gmail.com>
Currently, the top-level `validate_inputs` validator for the `PhBaseWorkChain` will always check if either the `qpoints` or `qpoints_distance` inputs are provided. However, there are cases where a higher-level work chain that wraps the `PhBaseWorkChain` might provide the q-points input on the fly. Such a work chain would have to set the `PhBaseWorkChain` validator to `None` in its own `define` method. However, as also discussed for a similar case for the `PwCalculation` in a389629, it's more elegant to check if the `qpoints_distance` and `qpoints` ports are present in the namespace. Typically a work chain that provides the q-points input on the fly will exclude these ports when exposing the `PhBaseWorkChain` inputs. By checking if the ports are present in the validator, we avoid having to set the validator to `None` as well in the higher-level work chain.
The release notes of `v4.5.0` did not add any explanation of the main changes and some useful code snippets. Since there was actually a breaking change related to how q-points are defined for the `PhBaseWorkChain`, adding some notes (that can then be copied to the documentation) is useful. Moreover, the subsections for the full list of changes did not respect the same order as previous release notes, which offended the OCD of one of the more picky and annoying developers. Hence, we correct this egregious error, and also add a specific section to put commits that only affect tests.
The `append_hubbard_parameter()` method of the `HubbardStructureData` class currently does not verify that the `atom_index` and `neighbour_index` values correspond to valid site indices in the structure. This means that the method will: - fail in case `translation` is set to `None` (as it attempts to access these site indices to obtain the distance and image of the nearest neighbour using periodic boundary conditions) - succeed in case the translation is specified, but fail once the code tries to write Hubbard card during the `prepare_for_submission` method of the `PwCalculation`. To have more consistent behaviour and avoid exceptions during the `upload` step of the submission process, we check here that the `atom_index` and `neighbour_index` are valid and raise a `ValueError` if they are not.
The `HubbardStructureData.append_hubbard_parameter()` method currently fails for structures that don't have 3-dimensional periodic boundary conditions. This is caused by a restriction in the StructureData.get_pymatgen_structure()` method, which raises a `ValueError` if the periodic boundary conditions are not (True, True, True). This has been fixed in a recent commit on `aiida-core`: aiidateam/aiida-core@adcce4b But this will take some time to be released and would restrict our compatibility to `aiida-core>=2.6.0`. Here we directly construct a list of `PeriodicSite` objects from the `sites` list of the object obtained from `StructureData.get_pymatgen()`, which can be both either a pymatgen `Structure` or `Molecule`, depending on the dimensionality of the structure. Co-authored-by: AndresOrtegaGuerrero <34098967+AndresOrtegaGuerrero@users.noreply.github.com>
The current implementation of the `seekpath_structure_analysis` calculation function is not compatible with the `HubbardStructureData` data class. Although the function runs without errors, the returned primitive structure is now simply a `StructureData` instance, and hence we lose all information related to the Hubbard parameters. Here we adapt the `seekpath_structure_analysis` calculation function so that it checks if the provided input `structure` is a `HubbardStructureData` instance. If so, the resulting primitive and conventional structures are converted into `HubbardStructureData` instances with the same _onsite_ Hubbard parameters as the input structure. Intersite parameters are much more challenging to preserve correctly when primitivizing the structure, since they cannot simply be defined in terms of the kinds of the structure. Rather, they are defined on pairs of site indices and transations, which the `get_explicit_kpoints_path` does not consider when primitivizing the structure. Hence, the `seekpath_structure_analysis` function currently does not support intersite parameters and will raise if the input `structure` has any defined. Co-authored-by: AndresOrtegaGuerrero <34098967+AndresOrtegaGuerrero@users.noreply.github.com>
If it is a molecular structure: * Adds the 'mt' to `ch_scf` in order to treat charged molecular systems * Performs the SCF calculations at Gamma point. --------- Co-authored-by: Xing Wang <xingwang1991@gmail.com>
The click option already returns a file handle, so the command itself should not try to open it again, which excepts.
Fixes aiidateam#1001 Some symmetry errors that ph.x can stop with are added. They are related to how the PHonon code handles internally symmetry, which unfortunately is slightly different from the PW code, which is used as a necessary previous step to run ph.x. This is generally due to some interal hard-coded thresholds. The solution is generally to run pw.x by specifying the lattice specific ibrav, instead of the more general ibrav=0. This cannot be handled though, as it would require to re-run the pw.x code. Co-authored-by: Marnik Bercx <mbercx@gmail.com>
* Enable Hubbard and Magnetic Moments for `XspectraCoreWorkChain` and `get_xspectra_structures` This commit enables `XspectraCoreWorkChain` and `get_xspectra_structures` to correctly parse `HubbardStructureData` and magnetic moments. Currently enabled: * `get_xspectra_structures` will preserve Hubbard data if the input structure is `HubbardStructureData` node type and scale parameters to match those required for the final supercell. * the `get_builder_from_protocol` function of `XspectraCoreWorkChain` will accept `initial_magnetic_moments` as an optional input and pass this information to the `scf` namespace. * Tests: Fix minor errors in tests from previous commit * `get_xspectra_structures()`: Fix handling of marked structures Updates `get_xspectra_structures()` to retrieve and re-apply Kind data to output structures so that Kind names are kept. The function will now also correctly determine the list of inequivalent atom sites if `standardize_structure = False` and return the correct set of marked structures. * `get_xspectra_structures()`: remove options for `initial_magnetization` Removes options for `initial_magnetization` from the function, since this has been shown to be superfluous in practice. * `XspectraCrystalWorkChain`: Enable Hubbard and Magnetic Data This commit fully enables the `XspectraCrystalWorkChain` to work with `HubbardStructureData` and to apply `initial_magnetic_moments` to all sub-processes. Automatically sets `standardize_structure` to `False` in the `get_xspectra_structures` step of the `WorkChain` if the input structure is `HubbardStructureData` as required by the `CalcFunction`. Also updates `get_xspectra_structures` with a new optional parameter `use_element_types` which instructs the `CalcFunction` to treat all `Kinds` of the same element as the same for the purposes of symmetry analysis even if the `kind_name`s are different. Defaults to `False`. * `XspectraCrystalWorkChain`: Fix handling of GIPAW pseudos Updates the `run_all_xspectra_core` step in the `XspectraCrystalWorkChain` to correctly assign the GIPAW pseudo provided for the element to all `Kind`s corresponding to the element, retaining the step to remove the GIPAW pseudo if there is only one atom of the absorbing element present in the structure (and thus, to avoid a crash due to incorrect pseudo allocation). * XSpectra `WorkChain`s: Refinements and Improvements Addresses requested changes in PR aiidateam#969 and refines the logic for assigning magnetic states to the absorbing atom depending on chosen core-hole treatment type, as some oversights were made in the case of magnetic systems. The absorbing atom is now always given a spin of 1 if it was 0 in the neutral system and we are using an XCH-type treatment. Otherwise, the spin is set to the value of its inherited `Kind`. Other refinements: * Fixed a typo where the core-hole treatments would override the overrides dictionary (the opposite to intended behaviour). * Removed unnecessary options for SpinType and initial_magnetic_moments in the `CoreWorkChain`. * Added tests for `get_xspectra_structures` to cover basic behaviour and correct handling of HubbardStructureData. * `get_xspectra_structures`: Bugfixes and Improvements Changes: * Fixes a bug where, if `use_element_types = True`, the symmetry data of the "non-cleaned" structure would be erroneously returned in `output_parameters` * Fixes a bug where, if `use_element_types = True`, the `kind_name` for each entry in `equivalent_sites_data` would be reported incorrectly. * Changes the default setting of `use_element_types` to `True`. * Changes the logic for converting the atomic number of each `type` in `spglib_tuple` used to generate the `cleaned_structure_tuple` to use `np.trunc(int()) instead of just `int()`. * Tests: Update `test_get_xspectra_structures` Updates `test_use_element_types` following changes to default function behaviour introduced in previous commit (c4701b3) * `get_xspectra_structures`: Consolidate Logic Removes various unneeded `if` statements and re-uses information generated during the process flow to simplify steps. * `get_xspectra_structures`: Reduce Use of `get_symmetry_dataset` Changes requested for PR aiidateam#969 Replaces some uses of `spglib.get_symmetry_dataset` with a single function call.
This PR refactors the `get_xspectra_structures` calcfunction to enable users to set symmetry data manually instead of relying on automatic symmetry analysis. * Moves supercell creation, processes for molecules, and generation of `equivalent_sites_data` to separate functions. * Adds functionality for users to manually provide symmetry data, thus enabling the `CalcFunction` to be used as a means to generate structures with user control over which exact sites to mark. * Fixes a bug discovered in the case where non-hubbard structures with custom Kind names lost their Kind names when converting the ASE supercell to `StructureData` type. * Fixes a small oversight in the tests where `spglib_settings` was mistakenly named `spglib_options`.
The more recent release v3.1.0 of `sphinx-autoapi` causes the build to fail because there are warnings about the generated API files not being found. The exact cause of the bug is unknown as of yet and therefore, as a workaround we are pinning the dependency for now.
…m#1033) An implementation that wraps the binary `bands.x` was missing. This program is used to find the symmetries of wavefunctions, to re-order the bands, and to perform basic post-processings, such as the calculation of the momentum operator. The current parser only performs basic parsing, with no specialized outputs for k-point wavefunction symmetries, nor momentum operator, nor bands. This can be, for instance, implemented over time depending on user request.
Adds an input namespace for the `XspectraCrystalWorkChain` which allows the user to define the spacegroup and equivalent sites data for the incoming structure, thus instructing the WorkChain to generate structures and run calculations for only the sites specified. Changes: * Adds the `symmetry_data` input namespace to `XspectraCrystalWorkChain`, which the `WorkChain` will use to generate structures and set the list of polarisation vectors to calculate. * Adds input validation steps for the symmetry data to check for required information and for entries which may cause a crash, though does not check for issues beyond this in order to maximise flexibility of use. * Fixes an oversight in `get_xspectra_structures` where the `supercell` entry was not returned to the outputs when external symmetry data were provided by the user.
…team#1039) The command would not specify the `CONTROL` key for the input parameters resulting in an exception in the upload step. This was not discovered by tests because the workflow is not actually run and the exception is only hit when the calcjob is actually executed.
In the new schema, the `number_of_atomic_wfc` is moved to the `atomic_structure` tag as an attribute. In case the former is not present, we extract the value from the latter.
Introduce a new input parameter, `nbands_factor`, to the PdosWorkChain. This parameter replicates the functionality available in the BandsWorkChain, allowing the calculation of additional bands during the PwCalculation (NSCF). It ensures that an appropriate number of extra bands are computed. This enhancement provides more flexibility and consistency in the band structure and PDOS workflows.
The `parse_data_files` option is added. When switched to `False` the parser will not parse the outputs files but just keep the raw files. The existing option `keep_plot_file` is deprecated in favor of the renamed `keep_data_files` option to make it coherent with the new option.
|
@AndresOrtegaGuerrero I finally managed to come back to this. Can you approve it so we can merge this? Or do you still have some comments? |
AndresOrtegaGuerrero
approved these changes
Jan 14, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Useful utility functions for
HubbardStructureDataare added:This helps issues like #991