The manuscript presents a novel developed tool "CondiDiag1.0" in the E3SM atmosphere model version 1 (EAMv1) for conditional sampling and budget analysis. The authors present a conceptual outline of their diagnostic tool, its features and its implementation into the EAMv1 model. The tool provides methods (controllable by the user via namelists) to sample model variables (and derived variables) at different points during the model's time stepping in a flexible manner. The sampled fields can contain instantaneous values, increments (tendencies), vertical integrals of quantities. Furthermore a conditional sampling method, based on evaluating variable fields against threshold values (and ranges) and selecting sampling variables, checkpoint and validity is presented. A user's guide exemplifies a general workflow and describes necessary namelist settings. The diagnostic tool is applied in a model use case and three different example applications for budget analysis, analysis with different sampling conditions, and increment analysis with sampling conditions. The tool is useful to study different processes in the complex model system but also for debugging purposes during model development. Although the tool is developed for EAMv1, CondiDiag can easily be ported to relatives in this model family, and already was included in EAMv1'a descendants.

The manuscript is very well written and structured. Even for readers with no knowledge of the EAM model system, it is easily understandable, also due to portability of the tool and the general description. Although, the general concept of (conditional) sampling and recording tendencies is not new, the provision of a modularized and lightweight diagnostic tool with easy to implement hooks in the model system facilitates the work of modelers and atmospheric scientists. The technical description of the diagnostic tool, the description of its implementation and application, completed by detailed examples including the necessary user inputs fits into the scope of GMD. The manuscript should be published, subject to few minor revisions.

ll. 181 ff.: If I understand this sentence correctly, it states, that some quantities are calculated at discrete points and become inconsistent with the model's prognostic state (at least as long as the variable field is not updated). Maybe the authors could clarify, that the values consistent with the prognostic state evolve within the time step, but the field values are not updated (only at the points of calculation).

l. 346: For readers familiar with EAMs structure and calling sequence it might be clear when (in the model's time stepping) the two subroutines tphysbc and tphysac are called, and it is even written in the manuscript (in the descriptions of Table B1 and B2), but it may be worth to mention the point in the calling sequence here (before/after coupling), which also explains the naming.

ll. 350 f.: All the implemented checkpoints are listed in Tables B1 and B2. However, at some point later in the manuscript (~l. 514) I got lost, as it was not clear to me where to find all the checkpoints and their calling sequence. Maybe the authors could clarify. Suggestion: "All checkpoints added to the EAMv1 subroutines tphysbc and tphysac are listed in Tables B1 and B2, respectively. Most of the checkpoints are implemented by inserting code like..."

l. 539: "model sub-cycling": Is it the sub-cycling in the model's parameterizations?

Technical corrections

l. 111: "5 hypothetical processes label" -> "five hypothetical processes labeled"

ll. 180 f.: "sequential method" -> "sequential splitting method"

l. 267: Could a link to Zenodo be inserted here?

l. 386: "carry" -> "carry out"

l. 431: add ")" after "checkpoint"

l. 529: "3 wind speed" -> "three wind speed"

General comments:

This paper documented a new model development tool called CondiDiags1.0 to facilitate conditional sampling and budget analysis in atmosphere model development. This tool is already being implemented in the EAM model with flexibility to be ported to models with similar data structure and time integration method. The authors also demonstrated the use of this tool with three carefully selected examples.

To select variables and monitor them at specified sampling condition is a common practice that is often conducted by model developers in developing new modules or in debugging. A general tool like this would avoid duplicated effort attempted by individual developers and help maintain a clean code base. The manuscript is well structured and written clearly. It is suitable to publish to GMD after addressing below comments, which are mostly minor.

Specific comments:

The manuscript indicated that the version 1 of this tool has implemented in EAM with several successful use cases. EAM is the target host model for now, but it is flexible to be used in other AGCMs. Some possible improvement to make the paper/tool more comprehendible for the general audience:

• Elaborate on terminology that is specific to EAM/CAM, just to name few: physics state, physics buffer, cam_in, cam_out, tphysbc vs tphysac…
• The zenodo doi linked two versions of EAMv1 with and without CondiDiags, but it is not straightforward to see the codes of CondiDiags and how it interfaces with EAM. Not sure about the best approach, but I wonder if the authors can supply with an additional package with standard CondiDiags and a template that could be used as an example for external users? Is there a general guideline about adopting ConndiDiags with other AGCM as a host model?
• It is not explicitly indicated that if CondiDiags has already be available in EAM code base and readily to be used for EAM developers?

Technical corrections:

In session 2.1, the definition of “process” and “component” seem ambiguous. Ln 117-119: indicate that deep convection contains two sub-components, with the parameterization of impact of convection on temperature and humidity, the parameterization of convective momentum transport. Is process B a more frequent case than processes without sub-processes? It might be useful to have some definition on process and component?

Ln 130. Is there a relationship between the location of where outfld is called to check-points? Is the location of outfld process-depended?

For the inactive checkpoint, are they off by default but can be turned on easily with name list change?

Ln 237: “If a value of 101 (moist) or 102 (dry) is used, the the….” Shoud be “…, then the”?

Session 5.2.4 The process of turning on vertical integral and assign moist/dry air mass for mass-weighting is a little hard to comprehend. Maybe try simplifying if possible…