Adjust fundamental operator set to respect order in gf_struct #342 #686
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
-In acc with the type gf_struct_t=vector<pair<int,vec<int/str>>> that describes the Block Green function structure this commit adjusts the fundamental operator set to respect this block-order -Contains unfixed test failures for atom_diag
|
I'll look at the code a bit later... Now I only have a quick question about |
|
You are indeed correct. The type is |
krivenko
reviewed
Mar 7, 2019
There was a problem hiding this comment.
There are only a couple of small remarks.
Besides, I fixed the test failures in krivenko@b84c865.
|
|
||
| /// The set represented as a plain `std::vector` | ||
| /// The basic container `std::vector<indices_t>` | ||
| using reduction_t = std::vector<indices_t>; |
There was a problem hiding this comment.
Now that fundamental_operator_set is just a vector with some convenience methods, I'd rather rename this type to data_t or something similar.
| } | ||
|
|
||
| // Dereference type for const_iterator | ||
| struct _cdress { | ||
| indices_t const &index; | ||
| int linear_index; | ||
| _cdress(typename map_t::const_iterator _it) : index(_it->first), linear_index(_it->second) {} | ||
| using base_const_iterator = triqs::utility::details::enum_iter<reduction_t::const_iterator>; |
There was a problem hiding this comment.
Drawing things from details namespace is not what one should be doing. Consider moving enum_iter into triqs::utility.
…_operator_set `fundamental_operator_set` used to store operator index combinations in the lexicographical order. Now they are stored in the order they were inserted.
|
LGTM, thank you! |
krivenko
added a commit
to krivenko/triqs
that referenced
this pull request
Aug 30, 2021
PR TRIQS#686 changed the order in which `fundamental_operator_set` stores index combinations. Before that PR, mutual order of two index combinations was dictated by the result of `operator<()`, which had been consistent with the way `many_body_operator` orders canonical operators within a monomial. Now the order of the index combinations and - consequently - of single particle bits forming a Fock state is arbitrary. When computing fermionic sign prefactor, the constructor of `imperative_operator` relied on ordering of the bits being consistent with the ordering of the monomial. PR TRIQS#686 broke that assumption, which resulted in a dangerous and hard-to-find bug -- sign of some matrix elements can be erroneously flipped. This commit fixes the issue by sorting monomials in `imperative_operator`'s constructor and revealing a possible sign change due to a permutation of canonical operators caused by `fops`.
This was referenced Aug 30, 2021
Wentzell
pushed a commit
that referenced
this pull request
Sep 9, 2021
PR #686 changed the order in which `fundamental_operator_set` stores index combinations. Before that PR, mutual order of two index combinations was dictated by the result of `operator<()`, which had been consistent with the way `many_body_operator` orders canonical operators within a monomial. Now the order of the index combinations and - consequently - of single particle bits forming a Fock state is arbitrary. When computing fermionic sign prefactor, the constructor of `imperative_operator` relied on ordering of the bits being consistent with the ordering of the monomial. PR #686 broke that assumption, which resulted in a dangerous and hard-to-find bug -- sign of some matrix elements can be erroneously flipped. This commit fixes the issue by sorting monomials in `imperative_operator`'s constructor and revealing a possible sign change due to a permutation of canonical operators caused by `fops`.
Wentzell
pushed a commit
that referenced
this pull request
Sep 9, 2021
PR #686 changed the order in which `fundamental_operator_set` stores index combinations. Before that PR, mutual order of two index combinations was dictated by the result of `operator<()`, which had been consistent with the way `many_body_operator` orders canonical operators within a monomial. Now the order of the index combinations and - consequently - of single particle bits forming a Fock state is arbitrary. When computing fermionic sign prefactor, the constructor of `imperative_operator` relied on ordering of the bits being consistent with the ordering of the monomial. PR #686 broke that assumption, which resulted in a dangerous and hard-to-find bug -- sign of some matrix elements can be erroneously flipped. This commit fixes the issue by sorting monomials in `imperative_operator`'s constructor and revealing a possible sign change due to a permutation of canonical operators caused by `fops`.
Wentzell
pushed a commit
that referenced
this pull request
Sep 9, 2021
PR #686 changed the order in which `fundamental_operator_set` stores index combinations. Before that PR, mutual order of two index combinations was dictated by the result of `operator<()`, which had been consistent with the way `many_body_operator` orders canonical operators within a monomial. Now the order of the index combinations and - consequently - of single particle bits forming a Fock state is arbitrary. When computing fermionic sign prefactor, the constructor of `imperative_operator` relied on ordering of the bits being consistent with the ordering of the monomial. PR #686 broke that assumption, which resulted in a dangerous and hard-to-find bug -- sign of some matrix elements can be erroneously flipped. This commit fixes the issue by sorting monomials in `imperative_operator`'s constructor and revealing a possible sign change due to a permutation of canonical operators caused by `fops`.
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.
In accordance with the type-change of
gf_struct_ttothat was introduced in a746ba5 this commit adjusts the
fundamental_operator_setto respect the order of blocks in gf_structThis PR still contains unfixed test failures for the atom_diag part of triqs.
@krivenko Could you comment on/review this PR and have a look at the test failures in atom_diag?