-
Notifications
You must be signed in to change notification settings - Fork 874
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 capability for Vasprun to read KPOINTS_OPT data #3509
Merged
Merged
Changes from 16 commits
Commits
Show all changes
37 commits
Select commit
Hold shift + click to select a range
ce30012
Add KPOINTS_OPT reading functionality to Vasprun
bfield1 909b98b
Update docstrings, fix names in Vasprun
bfield1 d3c136b
Test case for Vasprun kpoints_opt
bfield1 33aeb14
Bandstructure test for kpoints_opt vasprun.xml
bfield1 f750277
Ran my own calculation, so have projected data
bfield1 50c833b
Unittest for projected kpoints_opt
bfield1 1bda574
Change use_kpoints_opt to be default behaviour
bfield1 4c89b40
Merge branch 'master' into vasprun-kpoints-opt
bfield1 4ad198a
Update borg test to account for new test documents
bfield1 4ac674c
Rename new test file directory to kpoints_opt
bfield1 400776c
pre-commit auto-fixes
pre-commit-ci[bot] 6575ba4
Code linting from ruff (whitespace, line length)
bfield1 1b59aaa
Merge branch 'vasprun-kpoints-opt' of https://github.com/bfield1/pyma…
bfield1 58d2979
Support for KPOINTS_OPT in BSVasprun
bfield1 3372988
as_dict now reads KPOINTS_OPT parameters
bfield1 6c9da5e
Merge branch 'master' into vasprun-kpoints-opt
bfield1 73256ad
tweak Vasprun Attributes: doc str
janosh 4497f08
Merge branch 'master' into vasprun-kpoints-opt
bfield1 a691a45
Replace vasprun.xml for kpoints_opt with smaller file
bfield1 e12e73b
refactor get_band_structure
janosh 9889c50
Merge remote-tracking branch 'upstream/master' into vasprun-kpoints-opt
bfield1 071690d
Merge remote-tracking branch 'upstream/master' into vasprun-kpoints-opt
bfield1 27f9cd1
Merge branch 'master' into vasprun-kpoints-opt
bfield1 681a08a
Merge branch 'master' into vasprun-kpoints-opt
bfield1 6295e29
Merge branch 'master' into vasprun-kpoints-opt
janosh 56e854c
Merge branch 'master' into vasprun-kpoints-opt
bfield1 a2d4df7
Explanatory comment on parser restructure
bfield1 cf51ec3
Stick all KPOINTS_OPT properties in a container
bfield1 2dc1d70
Merge branch 'master' into vasprun-kpoints-opt
bfield1 931c85d
Merge branch 'master' into vasprun-kpoints-opt
bfield1 583e259
Merge branch 'master' into vasprun-kpoints-opt
bfield1 ecbd080
Merge branch 'master' into vasprun-kpoints-opt
bfield1 e40d40c
rename _ElectronicPropertiesContainer to KpointOptProps and turn into…
janosh 712da14
rename Vasprun.kpoints_opt_properties to kpoint_opt_props
janosh 0d090dd
Merge branch 'master' into pr/bfield1/3509
janosh 58622ed
fix typo kpoint_opt_props -> kpoints_opt_props
janosh 6c5d445
fix mypy
janosh File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
Fully automatic kpoint scheme | ||
0 | ||
Automatic | ||
25 |
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
Line_mode KPOINTS file | ||
10 | ||
Line_mode | ||
Reciprocal | ||
0.0 0.0 0.0 ! \Gamma | ||
0.5 0.0 0.5 ! X | ||
|
||
0.5 0.0 0.5 ! X | ||
0.5 0.25 0.75 ! W | ||
|
||
0.5 0.25 0.75 ! W | ||
0.375 0.375 0.75 ! K | ||
|
||
0.375 0.375 0.75 ! K | ||
0.0 0.0 0.0 ! \Gamma | ||
|
||
0.0 0.0 0.0 ! \Gamma | ||
0.5 0.5 0.5 ! L | ||
|
||
0.5 0.5 0.5 ! L | ||
0.625 0.25 0.625 ! U | ||
|
||
0.625 0.25 0.625 ! U | ||
0.5 0.25 0.75 ! W | ||
|
||
0.5 0.25 0.75 ! W | ||
0.5 0.5 0.5 ! L | ||
|
||
0.5 0.5 0.5 ! L | ||
0.375 0.375 0.75 ! K | ||
|
||
0.625 0.25 0.625 ! U | ||
0.5 0.0 0.5 ! X | ||
|
bfield1 marked this conversation as resolved.
Show resolved
Hide resolved
|
Binary file not shown.
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 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.
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.
@esoteric-ephemera If you're not too busy, could you take a look and let me know if the changes in this file all make sense to you?
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.
Yes sorry I will soon!
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.
These overall look pretty reasonable to me. @bfield1, are the changes to the structure of the XML parsing needed? It seems like you've added explicit triggers for when XML blocks are read.
Also, if a user specifies a KPOINTS_OPT file, it might make more sense to put the various
*_opt
quantities without the suffix?For many use cases, where KPOINTS_OPT isn't used, there would be 5 new top-level attrs that default to
None
, which is OK. Maybe it makes more sense to have underscored attrs that default to None and store the quantities computed with KPOINTS/KSPACING whenKPOINTS_OPT
is used?For example, when no KPOINTS_OPT file is used, or
LKPOINTS_OPT = False
:and when KPOINTS_OPT is used:
Just to keep things more organized and hopefully reflect what a user expects to get from a
Vasprun
.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.
Yes, we do need those changes. The prior 'end' condition for reading XML elements doesn't tell you which element it is nested within until after you have left that element. The 'start' condition is used to identify when we are entering certain blocks (but we have to wait until 'end' to read the data).
When using KPOINTS_OPT, some of the blocks can only be distinguished from their regular KPOINTS counterparts by knowing which block they are nested within. As such, I had to change the parser to read both start and end tags, and add a flag to track when we have entered (or left) certain blocks.
Regarding how to structure the data:
My choice of convention was mainly based on how the data is structured within the vasprun.xml file itself, as well as the calculation outputs. KPOINTS and KPOINTS_OPT are separate files, as are PROCAR and PROCAR_OPT. The vasprun.xml files stores the conventional KPOINTS data in the standard location and the KPOINTS_OPT data under special flags. The KPOINTS_OPT calculation is an extra non-self-consistent calculation run on top of the regular self-consistent calculation.
I also didn't want to change what the current variables in
Vasprun
were pointing to without proper consultation.That said, I am not opposed to making the KPOINTS_OPT data the default when it is present. You probably have a better idea of what the average user "expects" from a
Vasprun
than I do. I only recently started using KPOINTS_OPT too, so different people may have different conventions.One use-case of KPOINTS_OPT I was considering was doing a regular grid with normal KPOINTS (which you have to do) and a band structure with KPOINTS_OPT. In principle, one could get DOS data from the regular grid and band structure data from the KPOINTS_OPT data. But maybe this is a niche use case?
I would guess that typically someone cares most about the KPOINTS_OPT data when they specify it, so making that the prime data then using extra flags to get the underlying data probably makes sense. But also, I would expect the
Vasprun
class to reflect the data structure of the vasprun.xml file, so listing KPOINTS_OPT separately also makes sense. I suppose it depends which we value more.For what it's worth, I counted 10 new top-level attributes rather than 5.
tdos_opt
,idos_opt
,pdos_opt
,efermi_opt
,eigenvalues_kpoints_opt
,projected_eigenvalues_kpoints_opt
,projected_magnetisation_kpoints_opt
,kpoints_opt
,actual_kpoints_opt
, andactual_kpoints_weights_opt
, which are all the KPOINTS_OPT equivalents of their non-opt counterparts and are listed in separate fields in vasprun.xml. I can appreciate that having lots of usually-empty attributes floating around might be a bit messy, though. If we wanted to tidy up, maybe we could store these attributes inside a dictionary so we only have one new top-level attribute?Let me know your thoughts.
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.
this is very helpful information to understand why the code is as it is. could you insert this as a comment along with a date?
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.
would be interested to hear @utf opinion on this and also if it affects
atomate2
in some way?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 @bfield1! This is super helpful context and I appreciate the work you've put into this.
Re:
This is actually the default behavior of the Materials Project's bandstructure workflows, which means we should probably save some compute effort and revise these after this PR is merged. As they stand currently, two separate self-consistent calculations are performed to get the DOS from a uniform k-mesh, and the bandstructure from a line-mode k-mesh
I might lean towards this approach, or perhaps defining a small container class (e.g.,
electronic_properties
) that contains these 10 attrs (electronic_properties.tdos
,electronic_properties.idos
,...). The container class would be a top-level attr ofVasprun
. Hope that makes senseThere 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.
Done.
You'd probably want to double-check that VASP prints its output to vasprun.xml as expected when using KPOINTS_OPT, as it's a new feature so may have some bugs (the compilation of VASP I'm using doesn't write the projected eigenvalues to vasprun.xml properly, for instance). But if VASP behaves you might be able to save some effort, yes.
I have now implemented such a solution. A simple container class (
_ElectronicPropertiesContainer
) (which I made MSONable because it seemed straightforward) which is used in the attributeVasprun.kpoints_opt_properties
. It holds the electronic properties with their normal names (without the suffixes). The names might be a little wordy, but it's probably better to be more verbose than less.In principle, one could use such a container for the regular electronic properties too, but that's probably an unnecessary extra layer with no obvious benefits. Unless, maybe, we have setters/getters to the top-level attributes which intelligently decide whether to access the kpoints_opt or regular data, but that's getting ahead of ourselves. People can request such a feature if demand arises.
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 for these changes @bfield1! I'm happy with the current state of this PR. Re the "non-opt" electronic properties: just to avoid breaking changes, I prefer the way you've done things by not storing them in an
_ElectronicPropertiesContainer
.The option to transition to a container class for these is there, but not necessary now.