-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add feature: XspectraCoreWorkChain
#872
Add feature: XspectraCoreWorkChain
#872
Conversation
Added CalcJob implementations of the xspectra.x executable and upf2plotcore.sh shell script from the Quantum ESPRESSO library
Added Parser classes for the xspectra.x executable and upf2plotcore.sh shell script from the Quantum ESPRESSO library
Added entry points for both CalcJob and Parser classes required for XSpectra post-processing calculations
Change 'spectra_data' output to 'spectra' Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Change the caplitalization for XSpectraCalculation to XspectraCalculation Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Correct the capitalization of XSpectraParser to XspectraParser Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Correct the capitalization of XSpectraCalculation to XspectraCalculation Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Correct the capitalization of XSpectraParser to XspectraParser Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
…ved redundant file loop, and added new error code
Fixed the terms used in the XSpectra-specific error codes in order to make them easier to read.
Changed filename assigned to `_Plotcore_FILENAME` from `plotcore.out` to `stdout` in order to work properly with the `aiida-shell` plugin.
Made corrections to the parsing of various output parameters (e.g. energy levels and associated units) in both spin-polarised and unpolarised cases. An additional parameter `lsda` is also added to report explicitly the case of spin polarisation.
Adds tests of the `XspectraParser`, covering spin-polarised and non-spin-polarised cases, interrupted calculations, and XSpectra-specific error codes 313 and 314.
Adds the following features to the `XspectraCalculation` and `XspectraParser` classes: - A save file ('xanes.sav') is now reserved by default and is printed at the end of each calculation run or after a designated time limit. The file can then be used for re-starting halted calculations or re-plotting spectra from previously-finished calculations. - The `XspectraCalculation` class now copies the save file from a parent calculation if the calculation type is itself an XspectraCalculation, thus re-starts and re-plot runs are handled automatically. - An error code has been added (315) for calculations which safely exit after reaching their time limit, thus enabiling a restart. - Additional information is now included in the `output_parameters` node (e.g. the polarisation vectors used and whether the calculation was set to "xonly_plot").
Updates `XspectraParser` tests to work with changes made in a previous commit (commit 875fa58) and adds a new test for error code 315 (job exceeded time limit)
Addresses aiidateam#837 Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Addresses PR aiidateam#837 Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Addresses PR aiidateam#837 Changes error code from 315 to 400 to match conventions Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Addresses PR aiidateam#837 Required for commit aiidateam@746770e Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Addresses PR aiidateam#837 Required with commit aiidateam@746770e Co-authored-by: Sebastiaan Huber <mail@sphuber.net>
Adds information on the coordinate system used in the XSpectra calculation (either crystallographic or Cartesian). Also addresses a bug spotted in the stdout of XSpectra itself, where the epsilon/k-vector is reported by the code during the `read_save_file` subroutine as being in `[Cartesian frame]` regardless of the coordinate system used by the parent XSpectra calculation. Because of this, calculations where `xonly_plot=.true.` cannot meaningfully have metadata for the coordinate system used by the calculation recorded in the `output_parameters` dictionary by the parser. This fix also addresses the fact that the epsilon/k-vector is essentially reported twice in the event of a calculation restart: once when the input file is read and a second time when the save file is read.
Updates commit 9ef620c Previous commit stated that when reading the save file, XSpectra prints the epsilon/k-vector stored in the save file as being in Cartesian coordinates regardless the coordinate system used in the parent calculation. This statement was incorrect, as XSpectra always records the epsilon vector in cartesian coordinates. The parser now correctly records the `eps_k_vector_coords` entry in the event of re-plot calculations while skipping the entry for calculation restarts, since the epsilon/k-vector used is reported with the relevant coordinate system at the beginning of the stdout.
Improves the reliability of parsing information in the `XspectraParser` by collecting information from the CalcJob node's `parameter` node instead of using the stdout.
For the `XspectraParser` and related tests: * Changes the Parser to retrieve various information from the inputs of the CalcJob node rather than the stdout, since some information (e.g. polarisation vector and coordinate system) are not reported reliably. * Changes some of the keys in the `output_parameters` dictionary. * Updates the Parser tests to work with the new changes to the Parser itself.
Requested for aiidateam#853 For parameters Parsed from the calculation input, the commit changes their keys to those used in the input parameters: * `epsilon_vectors` => `xepsilon` * `vector_coord_system` => `xcoordcrys` * `only_plot_spectrum` => `xonly_plot` Also adds default values for these keys which match those set by `xspectra.x` and updates the relevant parser tests.
This commit adds a new `XspectraCoreWorkChain`, including basic tests. The `CoreWorkChain` performs the generic workflow for computing XANES spectra using `xspectra.x` and `pw.x`: * Run `pw.x` calculation on a structure with a core-hole present * Collect the core-wavefunction of the initial state * Run an `xspectra.x` calculation for each polarisation vector requested * Return all generated spectra in a single XyData node output * (Optionally) compute an XAS spectrum of the power sample of the input structure if the correct basis vectors are provided In addition to pre-defined protocol inputs, the WorkChain also uses pre-defined inputs for different core-hole approximations (or "treatments", as they are referred to in the WorkChain) and follow a similar infrastructure to the existing protocols system: * "full" - full-core-hole, where the core-hole state is approximated using a simple +1 counter charge (default). * "half" - half-core-hole, where the core-hole state is approximated using a +0.5 counter charge. * "xch_fixed" + "xch_smear" - excited-core-hole, where the core-hole state is approximated by occupying the first conduction band with the excited electron (in both "fixed" and "smearing" occupations, respectively) * "none" - no core hole, where no approximation is used. To be used only if no core-hole pseudopotential is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @PNOGillespie , great contribution. I have gone through most of the code but not all the details, but I trust this to be ok or we can fix it later. Just have some comments for now for slight improvements.
Changes requested for PR: aiidateam#872 (1) * Removes `get_powder_spectrum` and `get_all_spectra` CalcFunctions from `core.py` and moves them to their own files under `src/calculations/functions/xspectra/`. `get_all_spectra` is now renamed to `merge_spectra`. * Updates the docstrings for `get_powder_spectrum` and `merge_spectra` to describe what inputs are expected. Corrects the node type check when building the list of input spectra nodes in each case. Adds basic error handling for `get_powder_spectra`. * Changes the process flow of `core.py`: instead of using BaseWorkChain node labels and a labels list in the context, the WorkChain now uses the `append_` method from `aiida.engine` to create the list of XspectraBaseWorkChains being run by the CoreWorkChain instead of using labels. * Converts the input validator functions into `staticmethod`s. * Updates the inputs of `core_hole_treatments.yaml` for `xch_smear`. * Fixes various typos.
Hi @sphuber. I addressed the points that you mentioned. Regarding this converstation, I decided to leave Let me know if there is anything else that needs changing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @PNOGillespie . Just a couple final minor touches and this can be merged.
f78e0ee
to
f17b601
Compare
The `XspectraCoreWorkChain` takes a given input structure in which one atomic site is designated as the site for the absorbing atom and run all `XspectraCalculation`s as requested. The results are post-processed into a powder spectrum. This WorkChain makes use of as many features already implemented in `aiida-quantumespresso` as possible, however, it does require the `aiida-shell` plugin to run `upf2plotcore.sh` to generate the `core_wfc_data` input.
Overview
In this PR, we propose to implement a
CoreWorkChain
for XSpectra. This WorkChain will take a given input structure in which one atomic site is designated as the site for the absorbing atom (see inputs for more info) and run all XSpectra calculations requested. The aim is to provide a generic workflow process to cover the necessary parts for computing the XANES spectrum for a particular absorbing atom in a structure, which can then be used either as a standard sub-process in other WorkChains or self-standing as a means to simply automate analysis with XSpectra for a given structure. This WorkChain makes use of as many features already implemented inaiida-quantumespresso
as possible, however it does require the AiiDA-Shell plugin forrun_upf2plotcore
and thus will add it as a dependency.Process Flow
The steps of the WorkChain are:
inputs.run_replot = True
) in a single XyData node for easier plotting, and produce a representation of the XANES of a powder sample of the structure (if requested).Inputs
Important Inputs
Important inputs to take notice of are:
structure
- the input StructureData node for the WorkChain. The structure must contain at least one unique Kind which represents the absorbing atom and appears at one Site in the structure. The name of the absorbing atom Kind must match the abs_atom_marker in the inputs.abs_atom_marker
- a Str node designating the name of the Kind to be used as the absorbing atom. Defaults to "X".core_wfc_data
- a SinglefileData node containing the core wavefunction of the ground-state of the absorbing element, obtained by parsing the ground-state pseudopotential for the absorbing element with upf2plotcore.sh. Since this is normally obtained by AiiDA-Shell and thus (as far as I remember) can only be the stdout, the filename of this must be "stdout".eps_vectors
- a List node containing all the 3-vectors to be computed forxepsilon(1-3)
in thexspectra.x
calculation, thus also defining the number of XSpectra sub-processes to launch. Defaults to [[1.0, 0.0, 0.0], [0.0, 1.0, 0.0], [0.0, 0.0, 1.0]].get_powder_spectrum
- a Bool node which requests if the powder spectrum of the structure should be computed. Defaults to False. The CalcFunction associated to this will operate differently depending on the number of given spectra (from 1 to 3) using symmetry rules which, since no symmetry information can be obtained by the WorkChain in advance, the WorkChain will filter out the correct spectra to use. The process will be skipped with a warning in the logs if the spectra required to produce the powder spectrum are not present.run_replot
- a Bool node which, ifTrue
, requests a secondxs_plot
step to re-plot the final spectrum produced byxs_prod
. Set toFalse
by default. Uses thereplot
protocol within theXspectraBaseWorkChain
to generate inputs when usingget_builder_from_protocol()
.Core-Hole Treatments
The WorkChain contains a set of pre-defined input settings for the SCF step which correspond to different core-hole approximations (referred to as
treatment
s in the code) needed to handle the presence of the excited electron in the calculation. The method employed here in the code is a copy of the YAML-format system used to define and retrieve protocol inputs and uses the following presets:full
(default) - "full-core-hole" (FCH) method, in which the excited electron is balanced out by a simple +1 counter charge. This approximation is acceptable for most elements and avoids the need for a spin-polarised simulation of the excited state.half
- "half-core-hole" (HCH) method, which works the same asfull
but uses a +0.5 charge - requires a core-hole pseudopotential with a core-hole of half an electron (e.g. 1s1.5). Useful for some core-holes (e.g. carbon) where the FCH method works poorlyxch_fixed
&xch_smear
- "excited-core-hole" (XCH) method (for systems of fixed and smeared populations, respectively), in which the excited electron is included explicitly in the system - typically more costly as this makes the calculation spin-polarised but accurate for any element.none
- no core-hole, which simply counteracts the default value and provides no core-hole approximation - only usable if there is no core-hole in the simulation.The settings are applied to
scf.pw.parameters
during theget_builder_from_protocol
method and acts after theprotocol
defaults are obtained but before theoverrides
are applied - thus ensuring that the overrides are always applied as a final step regardless.