DCore: Integrated DMFT software for correlated electrons

1- Flexible and easy to use package for DMFT calculations supporting state-of-the-art impurity solvers and ab-initio models constructed from DFT

2- Structure and quality of the presentation in the paper very good in general

3- Nice examples for typical kinds of calculations

1- Several minor issues with clarity of the presentation

2- Explanations in parts not quite complete enough in my opinion

The authors present a new program package for performing DMFT calculations for multi-orbital Hubbard models. Supported are both simple predefined lattice models with user-specified parameters as well as ab-initio models constructed from DFT using a Hamiltonian in Wannier90 format. Interfaces to multiple existing solvers for the auxiliary Anderson impurity model are implemented and the user can flexibly choose which one to use, including multiple state-of-the-art CT-QMC solvers from the ALPS and TRIQS projects and an exact diagonalization solver.

While there are a few packages for such calculations already and writing a simple DMFT implementation is not very complex, an additional package, especially if it is applicable to a wide range of models, featureful, easy to use, and open-source (and even interfaces with multiple different impurity solvers) is certainly useful and if the package actually ends up helping people do DMFT calculations without the need for 'extensive expert knowledge', as stated in the introduction, a welcome addition.

The presentation in the paper is well structured in my opinion, giving first the background, then an overview of the structure of the package, detailing the input format for the specification of the model and configuration of the calculation and the output format of the results before coming to the technical detail of the installation procedure and presenting a few helpful examples illustrating how input is provided and results evaluated for some typical models.

All in all, I think that both the presented program package as well as this paper are very nice work and that it is suitable for publication with at most minor revisions necessary. However, I have also noticed that a new journal 'SciPost Physics Codebases' apparently has been or is about to be launched, which would usually be a better fit for a paper like this one, but given that I saw no trace of that yet when this paper was first submitted and similar articles have been published in this journal before, that might not be relevant at the moment.

In the following paragraphs, I give short comments on each section individually pointing out some minor issues I found that need revision or could be improved in my opinion.

The introduction is good, although it might be helpful to additionally add references to the applications of DFT+DMFT listed at the end of the first paragraph, and in their mention of the TRIQS project, the authors almost certainly meant to write 'implement their own DMFT code' rather than 'DFT code'.

Section 2 on the background is rather short, but given that the program does not rely on a specific type of impurity solver and the DMFT algorithm can in principle be summarized very succinctly I do not think that this is a problem, although a more detailed description could be added in some places, for example on the adjustment of mu which is just mentioned in passing or the self-energy symmetrization and double-counting correction mentioned in 2.4. Most importantly, some minor issues should be corrected to improve the clarity of the presentation. In particular, some issues I noticed are
- in the first term of eq. (1) i and j go over the elements of 'crsh', while the following text explains explicitly that this sum goes over all shells
- it is not explained how orbitals are or should be grouped into shells
- the text below (6) and in the caption of Fig. 1 say that the k-average is denoted by <...>, while actually <...>_k is used
- the self-energy sometimes does and sometimes does not have an extra S parameter that 'indexes correated shells' with no extra explanation, which might surprise readers unfamiliar with the subject
- the hybridization function being a matrix is mentioned before it is ever introduced, possibly where the self-energy should have been mentioned instead
- Fig. 1 is never explicitly referred to in the text
Also, the only reference in the entire section is to a review suggested as further reading, which differs a little in notation from the presentation here and is so comprehensive that the authors might help readers who wish to quickly read up on details by providing more specific guidance or additional references to material that is shorter or has a more introductory-level approach. Further, it is claimed that several methods of double-counting correction are supported, but later one specific formula is given as the used correction in eq. (8) (which should also carry an explicit reference to the appropriate literature) and I was not able to find any other indications of multiple supported methods either here or in the parts of the online manual I read. It is not clear to me what specifically distinguishes the points listed in section 2.4 from other functionality either. The purpose of that section should be stated more clearly (or possibly the content reorganized) and adding at least slightly more details to each point there could help clarifying the intended use cases and specific algorithmic / implementation details (with explicit literature references if appropriate).

Section 3 nicely lays out the structure of the package. The only minor issues I can possibly think of are that the figure suggests two different input files for dcore_pre and dcore while the text specifies a single text file, that one single arrow pointing from impurity solvers to dcore is probably not the best way to graphically represent that relationship (it is at least not the same as in the other cases where such an arrow is used, perhaps a double-headed arrow or two arrows would be better), and that the dcore_check program is missing from this section entirely for some reason.

Section 4.1 is a good summary of the available input parameters, but only the parameters of the model block are explained in detail. I think that explanations how the important parameters of the other blocks, especially system, should be used, possibly even just their names which are mostly missing now, would be helpful additions; if more detailed explanations are not given, at least a more explicit reference to the online reference manual should be added. Apart from that, minor issues are that the 'included blocks' sentence in the first paragraph, apart from the typo, could be expressed more clearly (i.e. that all programs usually read the same file, but that some blocks are, even if present, irrelevant to some of the programs) and that the image for the 'cubic' lattice seems a little visually cluttered and possibly confusing to me, partially also due to the inconsistency that the red cube does not indicate a unit cell while the red squares in the 'square' case do if I interpret the images correctly.

Section 4.2 is a good summary as well. Points that I would clarify are what the 'kind' of correlated shell specifically refers to in the paragraph on dcore_pre and what quantity specifically is called the 'density of states' in this context in the paragraph on dcore_post. There are some potentially confusing typos here as well: the dcore paragraph incorrectly begins with 'dcore_pre' and the parenthesized 'renormalization factor' is placed between 'chemical' and 'potential' instead of after both above eq. (9).

The installation section currently only refers to the online documentation. I think it would be better to give the installation commands at least for the simplest case (e.g. assuming some reasonably normal configuration, that the prerequisites are already installed and that no problems occur) in the paper as well, e.g. four lines for cloning the repository, calling cmake, make and make install or something short like that, so that a reader could follow the paper from beginning to end without having to consult much (or ideally any) additional material under ideal conditions.

Section 6 presents three good examples (the first with multiple slightly different calculations) that nicely illustrate typical use cases: First one very simple square-lattice one-orbital model treated both with exact diagonalization and CT-QMC and then used to demonstrate the Wannier90 interface and calculations with antiferromagnetism, then a multi-orbital model with an interesting physical feature from recent research, and finally a multi-orbital model for the t_2g manifold of SrVO_3 using a Wannier Hamiltonian from DFT as input data.

Minor issues in section 6.1.2 are the in my opinion unclear explanation of the averaging influenced by sigma_mix (i.e. what exactly is averaged and when) and lack of an explanation of what the particular significance of its numerical value is, the slightly ambiguous phrasing of what exactly is executed in parallel at the bottom of the same page, and the description of the restart option, in particular what exactly it does, how it differs from just increasing max_step if it does, and, in that case, why it might be preferable to use it. Further, I find the advice to reduce sigma_mix if the convergence graph exhibits oscillations surprising; I would rather have expected the opposite here if anything, assuming that a higher numerical value of sigma_mix means more influence from earlier self-energy, but then again sigma_mix is not really explained in detail as mentioned. Also, considering that use by non-experts is a stated goal, I am not sure if it is very helpful to instruct the user to just enter some values of unclear origin like 0.5 or 1.0 for not well explained parameters like sigma_mix; I do not think that, having read this paper, a non-expert could be confident in the choice of parameters like sigma_mix. Advice like to change sigma_mix in case of oscillations is probably helpful in such cases (if correct), but advice on how to set it to begin with or specifying whether it is usually even necessary to set it manually would be a good addition. To the parameters of the CT-HYB-SEGMENT solver in 6.1.4 something similar applies, but if that solver is a special case (as the ALPS CT-HYB solver is later used with only a timelimit as configuration) then it would be good to point out explicitly that different solvers might require different amounts of configuration to get good results (and maybe also which solver should be used to avoid manual configuration as much as possible).

In section 6.1.3, the analytical continuation is glossed over, and it is not explained in depth anywhere else in the paper either. Considering the potential influence on the quality of the results, perhaps at least some short advice or a reference in case of problems in the users' own calculations might be appropriate. Further, in my own attempt to reproduce the results shown here, A(k, omega) looked significantly different from Fig. 7a. The artificial features that are explained to come from the discretization to three bath sites were not recognizable, instead even with n_bath = 3 and using the ED solver my results looked more like 7b than 7a. Maybe the authors can think of a reason for this, possibly I made a mistake somewhere, in that case the relevant step should probably be explained more clearly and otherwise the wrong part be fixed. For the plots similar to Fig. 7 it might be also helpful to note that to generate as nice plots as the authors show, the range of the colorbar might need to be restricted manually. The plot scripts generated by dcore_post do not restrict the range, which can result in a rather homogeneous look due to tiny outlier spots, as it happens in Fig. 13 for example.

The only minor issues with 6.1.4 are, as mentioned, that it might be hard for non-experts to know what values to choose for some of the CT-QMC solver parameters (N_MEAS is for example mentioned as an important parameter but not explained at all) and that the THERMALIZATION parameter is often misspelled and missing the second I. Also, one could still attempt an automatic convergence check, especially if the size of the statistical errors can be estimated, even if it might be less reliable. If the implemented convergence check can be activated for a CT-QMC solver and would work when the tolerance is set higher than the statistical error, it would be good to state that explcitly (or that it can not be used or would definitely not work if that is not the case).

In section 6.1.6, the specific Wannier90-format input is not provided. Not knowing precisely what needs to be specified, my first attempt to change the file from 6.1.5 was not accepted by DCore, but a much larger file with all zero combinations added was. To generate this, I modified a script provided in a DCore online tutorial for a similar three-dimensional model, but such a script (or directly the input) for this specific example was not provided there. It would be helpful if the authors provide the input in some way, e.g. by adding the examples from the paper as tutorials to the online documentation as well and providing the input files there (and adding an explicit reference to them in the paper). Also, how to get the spin moment data shown in Fig. 10 is not explained. A note mentioning where to get it (e.g. to use the terminal output of dcore if that is really the easiest way) should be added.

In section 6.2, there is one minor issue by itself in the missing hermitian conjugate part of the spin-flip and pair-hopping terms of eq. (17) in comparison to eq. (1) of reference 24. Having a quick look at it, this might actually be the 'correct' form of the interaction, but the reference cited here explicitly adds it so the difference should at least be explained for clarity. Another minor issue is the consistency between the examples: here, interaction = kanamori is specified explicitly in the parameters while that is not done in the previous example. Looking into the online reference manual, kanamori is the default setting, but if that is relied on in section 6.1 it would be good to make that as clear as possible and mention it there or the parameter should be added explicitly there as well. The same applies to the use of first the temperature parameter T in 6.1 and then the inverse temperature parameter beta in 6.2.

In section 6.3, there is a typo in the section title and I find it strange that the Kanamori interaction parameters differ slightly between the text (second sentence of 6.3.2) and the parameter snippet shown below it, especially considering that the version of the tutorial in the online manual has the same values as the text. Also, if the colorbar range in Fig. 13 were reduced, the quantitatively different areas of the plots might be easier to distinguish visually.

In my own attempts to reproduce the results using the ALPS CT-HYB solver, i.e. those of sections 6.2 and 6.3, I also noticed that the solver sometimes terminated early / crashed with a rather unhelpful error message, with the solver printing an exception message involving 'Acceptance_rate_global_shift' and DCore then printing another exception message failing to access the sign, which would less often occur when raising the timelimit parameter, and the perturbation orders before and after measurement would often not be as close as in the example output in 6.2.2; in fact, the one before measurement would sometimes be -nan. To me this seems like possibly a problem due to too little thermalization time, but is especially surprising as I was calculating this on a fairly new machine with, I would assume, not significantly worse single-core performance than whatever the authors used. A comment on such potential issues in the example and a better error message in such cases in the program should ideally be added or, if I made an obvious mistake, clearer instructions be given in the relevant part.

1- Please consider fixing some or all of the minor issues mentioned in my comments above, particularly those in the part on section 2.