We thank you for your handling of our manuscript entitled "DCore: Integrated DMFT software for correlated electrons" and the referee for his/her very careful reading and a lot of feedback. The referee accepts the usefulness of the DFT+DMFT program (DCore) presented in the manuscript and is satisfied with the quality of the manuscript. The referee explicitly says ``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''. The referee however provides many suggestions/comments for minor revisions (mainly for improving the readability) throughout the manuscript. We examined each suggestion/comment very carefully and made minor revisions throughout the manuscript. We reply to the comments one by one below.

Best regards, Hiroshi Shinaoka, Junya Otsuki, Mitsuaki Kawamura, Nayuta Takemori, Kazuyoshi Yoshimi

Comment on Section 3

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.

Thank you for giving us useful comments for improving the readability. We've updated Figure 3 and added a description of dcore_check following the comments.

Comment on Section 4

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.

Thank you for pointing out the insufficient description for input parameters in blocks other than the model block. We have added an explicit reference to the online manual in each block. In addition, we have updated the description in the tool block.

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.

We have updated the first paragraph of Sec. 4.1 and Figure 4 following the comments.

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).

Thank you for pointing out the confusing terminology. We have replaced density of states by spectral function and fixed the typo following the comments.

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.

Thank you for the suggestions. We provide typical building commands in the revised manuscript.

Comment on Section 6

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.

We have added, at the end of 2.2, an explanation for averaging influenced by sigma_mix with its explicit definition in Eq.(11). We have added more descriptions on MPI parallelization in Sec. 2.3 of the revised manuscript. The restart option is now explained in more detail in 6.1.2. If restart=True is activated, "then, dcore uses the final result for \Sigma(i\omega_n) in the previous run as the initial state and executes additional maxstep iterations. We note that the default is restart=False, which means the self-consistent loop is started over even though the previous result exists in the current directory."

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.

The explicit definition for sigma_mix is now provided in Eq.(11). A larger numerical value of sigma_mix means more influence from new self-energy. We believe that the description is now clear.

For a guide for non-experts, we have added more introductory explanations for how to choose and change the value of sigma_mix. In the following, we quote the sentences which we have added below Eq.(17): "sigma_mix specifies the mixing parameter w in Eq. (11). The optimal value of sigma_mix depends on models and parameters. Generally, a larger value of sigma_mix (1 at the largest) can lead to a faster convergence, but may result in a bad convergence (e.g., oscillation and discontinuous change). A recommended strategy is that one starts from a large value such as 1and 0.5 and decreases it if the convergence graph (see below) does not show a tendency of convergence."

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).

Thank you for the suggestion. We have added one paragraph at the end of Sec. 6.1.4 to clarify this point.

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.

We have added two paragraphs: The last paragraph in 6.1.3 mentions a possible unphysical result (negative spectrum) and its workaround, and the third last paragraph in 6.1.4 describes a possible uncertainty of analytical continuation when the self-energy involves statistical errors.

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.

We have updated the online tutorial to be fully consistent with the manuscript. The exact input file is now provided there. We have confirmed in two different environments, that Fig.8(a) [Fig.7(a) in the previous manuscript] is indeed obtained.

We mention at the beginning of 6.1 that the input is available in the online tutorial.

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.

We have added the sentence "We note that the range of the color bar needs to be changed manually to obtain a distinct spectrum." after Fig.8(a) is mentioned in 6.1.3.

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.

Thank you for pointing this. We have added an explanation for N_MEAS in 6.1.4. Typos of THERMALIZATION has been fixed.

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).

That's right. One can use the automatic convergence check if the magnitude of statistical errors is known in advance. For better usage, we have added a new parameter n_converge, which controls the convergence check. The DMFT loop is terminated when the convergence criterion is satisfied n_converge times consecutively. This prevents the DMFT loop from being terminated prematurely.

We added a paragraph at the end of 6.1.4, and explain how to use the convergence check for QMC solvers. Thank you for bringing our attention to this.

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).

We have updated the online tutorial and provide the full input files as well as a script for generating the Wannier90-format input. We have added a link to the online tutorial in the second paragraph of 6.1.6.

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.

The spin moment data is easily obtained using a future implemented in the GitHub repository. We have merged it into the master branch. Fig.10 is now automatically generated by dcore_check. The online tutorial is also updated to be consistent with the manuscript.

We thank the referee for making us realize this issue.

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.

Thank you for pointing out the inconsistency and typos. We have fixed the equation for the Hamiltonian and remove the parameter interaction for consistency with other examples. We have also added a description of the parameters T and beta.

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.

Thank you for pointing out the typo. We have fixed the interaction parameters in the parameter snippet. We changed the color bar range of Fig. 14 and added the label for the spectrum.

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.

Thank you for your efforts in reproducing the data and the inconvenience. We have to agree that controlling the results of QMC calculations is still difficult due to their sensitivity to the number of processors and simulation time. It seems that the QMC program runs very slowly in your environment due to some unknown reasons. Each QMC code may behave differently depending on the environment and thus it is difficult to provide a general solution. We have added one paragraph to warn the user of the instability of QMC and recommend the user to create an issue on GitHub if any problem.

* Section 2: We have added Figure 1 and explained more technical details of DFT+DMFT calculations. We have added Sec. 2.3 on MPI parallelization and have removed the last subsection in Sec. 2.
* Section 3: We have updated Figure 3 and added a description of the program **dcore_pre** following the suggestions.
* Section 4: We have made minor updates for Figure 4 and updated the text following the suggestions.
* Section 6.1: We have added more descriptions especially on technical details following the suggestions.
* We have made minor revisions through the manuscript to improve the readability following the suggestions and comments.