Dear Shu and co-authors;

Thank you for your detailed responses to the referees, who have now sent their reports. I also made a thorough read through the paper, and have several minor points that I would like to see addressed -- in the text and/or in a response to these inquiries -- before publication. Some of these are extremely minor; others may address some of the early concerns that the reviewers had about the relationship between PIHM and SHUD, and could be the reason that one of the reviewers gave the paper a relatively low rating despite indicating that it should be published as-is. I hope that these help to improve the final paper and streamline the rest of its process at GMD, and that you do not find them burdensome.

Line numbers in revised paper (without tracked changes)

(1) L60 - "a heritage" is a strange use. Perhaps replace with "an intellectual descendant"?

(2) L447, Sect4.1. It seems that PIHM was rewritten in C++ in late 2019; I would suggest including this as a feature of SHUD while noting that the current developers of PIHM clearly agree! (There is not yet a release in this GitHub repo, but acknowledging it with some kind of web reference would be good.)
https://github.com/shulele/PIHM-4.0

(3) Sect4.1. "user-friendly": Is this just the ability to input ASCII or binary? Or does it include something else about how to pass those files to the model? If the former, I would suggest "flexible" rather than "user-friendly".

(4) L448-449. "Every function in the code has been rewritten, so the functions, algorithm or data structure between SHUD and PIHM are incompatible."
(a) I believe that you mean "and"
(b) Rewriting every function does not necessarily make code incompatible, if the interfaces to the functions stay the same. Could you add the necessary logic to this?

(5) L455. Please elaborate "has been greatly enhanced" with specific examples (and perhaps less superlative language unless you find it to be warranted)

(6) L467. Reword: as a computer model, SHUD is incapable of redesigning anything.

(7) L469. Could you explain what you mean by "unified functions"? Do you mean functions with standardized I/O to make it easier for the user to intuit how to interact with SHUD?

(8) L474-475. There must be some way of referencing these R scripts. Is it possible to create a doi-enabled release of https://github.com/SHUD-System/SHUDtoolbox to Zenodo so this can be properly referenced with a doi?

(9) GMD editorial staff will check this too -- but so you know: EGU journals require in-text citations to code. Therefore, you should cite yourselves inline as appropriate and add the appropriate references to the reference list.

(10) I will not request that you do this, but if you have any information on compute time or benchmarks against PIHM, this could add to your agruments for why you found it necessary to write SHUD.

Dear Lele Shu et al.,

Thank you for your thoughtful responses to the editorial comments -- I know that these can be annoying after making it through peer review.

I now have only three requests:

(1) Please use your Zenodo dois to create items for the reference list that you cite throughout the document in all relevant places in which you mention material in online code repositories. I know it may seem embarrassing to cite yourself so often, but this is indeed what EGU journals would like. Indeed, if you do not do this now, you will be asked to do so later. As an example of a paper of mine in which I had to do this quite a lot: https://www.hydrol-earth-syst-sci.net/23/2065/2019/.

(2) Please consider moving your "future work" to its own section, or perhaps not including it. I can see its use, but I am afraid that it weakens and dilutes the conclusions. Your co-authors may have insights about this.

(3) Please have one of your native-English-speaking co-authors review the text for English-language usage. I could fully understand your meaning -- despite not being a trained hydrologist myself -- and that's very encouraging. However, some of your longer additions might be difficult for our non-subject-matter-expert copyediting staff to decipher.