Development: Support QuantumESPRESSO v7.2
#32
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
mbercx
force-pushed
the
new/scfhubbard-7.1
branch
from
4b8ddc1
to
3865ca5
Compare
mbercx
reviewed
Mar 1, 2023
src/aiida_quantumespresso_hp/calculations/functions/structure_relabel_kinds.py
Outdated
Show resolved
Hide resolved
bastonero
changed the title
v7.1v7.2
|
@bastonero |
The calcfunction for relabelling the structure data is adapted to keep track of the initial starting magnetization and to relabel each chemical symbol starting from 0. Capital letters are used when the number is greater than 9.
Update the reorder function using the `HubbardUtils` of aiida-quantumespresso.
The following changes are applied: * New validation functions are added to support different case scenario * The `HUBBARD.dat` file is now retrieved temporarely * The `structure` input is replaced by `hubbard_structure` * New exit code is added if the parsing failure of `HUBBARD.dat` * Symlinking of `parent_scf` is added * Other adaptations for post-processing options
The following changes are applied: * Split the parse of stdout in a separate file * Adapt the logic for parsing U and U+V cases * Add `HUBBARD.dat` parsing function * Adapt logic for different post-processings, i.e. when parallelizing over atom or q points * Add out of walltime exit message
Update dependencies, authors and entry points.
Update the conftest.py with useful fixtures, and add pseudo potentials fixtures for future protocols.
Add the following methods: * `set_tot_magnetization`: useful for setting the total magnetization to an integer value, otherwise QE will complain * `is_perturb_only_atom`: used to detect the "perturb_only_atom" key in the hp.parameters (used in different validations)
The following changes are applied: * Introduce the `clean_workdir` input * Introduce automatic setting of `max_seconds` * Add the `get_builder_from_protocol` method
A work chain for parallelizing over q points on single perturbed atom is introduced. The parallelization is simple and it launches an `HpBaseWorkChain` for each single independent q point that it finds. This implementation works starting from Quantum ESPRESSO v7.2.
The following changes have been applied: * Inspect methods are added to the outline to check status of completed sub processes * Possibility of parallelizing over q points * `clean_workdir` input is added
The following changes are applied: * Introduction of `clean_workdir` input * Introduction of `parallelize_qpoints` input * The `qpoints_distance` input, along method in the outline is added in order to automatically assign the q point grid given a distance between points in reciprocal space * The `get_builder_from_protocol` is added to fill automatically a builder ready to submit
The following changes are applied: * Inputs adapted for handling both onsite and intersite cases (U and U+V) * New inputs for skipping the first relaxation and for controlling the frequency of the call to the relax workflow * Validation for magnetic inputs * Outline change: always perform an scf with smearing, than recognize if it is a metal or insultaor; if insulator, than do scf with fixed occupation. * The check on convergence over Hubbard parameters is performed separately on onsite (U) and intersite (V). * Protocols through the `get_builder_from_protocol` * `clean_workdir` input
bastonero
force-pushed
the
new/scfhubbard-7.1
branch
from
d821c78
to
ab45d9e
Compare
sphuber
approved these changes
May 3, 2023
There was a problem hiding this comment.
Thanks a lot @bastonero for all of this work! I have given most of the changes a look and it looks very reasonable. Since the changes are quite substantial and the original code was anyway very alpha, I propose we merge this as is, unless @mbercx still wants to have a look.
I'm sure it's great work. 😉 Also I won't have time for a proper code review anytime soon, so feel free to go ahead! Let's keep testing it in the field and see what we can improve (if anything). |
|
Bombs away! |
|
Thanks a lot! |
This was referenced May 4, 2023
6 tasks
This was referenced May 7, 2023
Closed
Closed
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.
The QuantumESPRESSO binaries used in this plugin (
pw.xandhp.x) changed the IO interface in the newv7.1release. The main improvement is provided by the introduction of theHubbardStructureDatain the aiida-quantumespresso, which allows for an easy handling of the Hubbard parameters along with the structure information.We want to provide full support for the new version, and release robust workflows.
Here a to do list for the merge:
HpCalculationandHpParser(requires review and tests)get_builder_from_protocolmethod - implemented, need discussionDiscussion:
protocols: shall we introduce theqpoints_distancein theHpBaseWorkChain? How to do it, since the structure could be absent? Maybe we can introduce it only for theHpMainWorkChain, which is handling the parallelization (meaning thehubbard_structureshould be specified)?workflows: how to handle differentwalltimes, e.g. when only performing anhp.xinitialization for parallelizing over atoms?