General comments:

This paper describes a new set of data model components that allow accessing a variety of data sources via a uniform interface. This is a valuable approach to make it easier for model developers and users to access forcing data for their modeling systems without needing to learn a new interface or write substantial amounts of code to access data for each new data source. These data models are part of the Community Surface Dynamic Modeling System (CSDMS). Not having familiarity with the CSDMS modeling system, it's hard for me to speak to how much use this will get, but these new data model components do seem useful. I also enjoyed taking this opportunity to learn a little bit about CSDMS, which seems like a valuable project for the community.

The paper is organized well and is well-written. I appreciate the inclusion of a code snippet (Figure 2), illustrating how these data components can be used in practice. The associated web page (https://csdms.colorado.edu/wiki/DataComponents) gives a catalog of existing data models and instructions for creating a new data model, which is also very useful.

Specific comments:

1. Many of the data components involve downloading data from a remote server. Can the authors include some more details on the logic for this? Particularly for time-varying data, I wasn’t clear on whether the full time series is downloaded at once – e.g., in the initialize step – or if each time sample is downloaded on an as-needed basis in the run loop. If the full time series is downloaded in initialization, is there a way to specify just a subset of the full time series for downloading? If each time sample is downloaded on an as-needed basis, is there a significant performance impact of these repeated remote accesses? The authors mention caching of the data (line 169); can they elaborate a bit on how this works? Does this mean that, if you run the same data component multiple times on the same machine, the download will only happen the first time, or is the caching only within a single model run?
2. It is helpful that the authors included some use cases (section 3.2) to provide some example usage of these data components. However, I didn’t find much value after the first two: The additional use cases didn’t really help me gain any better understanding of how these data model components are used. (This is not to say that the first two were necessarily the most valuable: I just think that, after reading about two different use cases, I didn’t get much out of the additional use cases.) I recommend that the authors do one or both of these:
   • Cut one or two of these use cases
   • Rework the description of these use cases to focus more on the mechanics of using the data components and less on other aspects of the specific scientific study. At the end of each use case, the authors briefly mention what is interesting about the use case, such as (Lines 433-434), “demonstrates how to use the API of the Data Component instead of the Babelized component for data access, when there is no need to couple Data and Model Components for analysis”. But it’s hard for me to get a clear picture of how this works based on the given descriptions. I would be interested in more focus on the mechanics of the data model use, through schematic figures and/or code snippets (actual code or pseudocode), and less focus on the scientific results (which is not the main point of this paper).
3. The authors may also be interested in the Community Data Models for Earth Predictive Systems (CDEPS; see https://github.com/ESCOMP/CDEPS and https://escomp.github.io/CDEPS/versions/master/html/index.html). While these are aimed more specifically at Earth system models that are coupled using ESMF, their concept is somewhat similar to the data components described here. (I leave it up to the authors whether they think this is worth citing.)

Technical corrections

This paper is generally very well written, but there are a few minor grammatical / technical errors. Ones I noticed are:

1. Line 66: "and together with" should be "together with"
2. Line 176: Change "And the Babelizer will use" to "The Babelizer will then use"
3. Figure 2b: There is a vertical bar at the end of the line setting var_grid which appears to be the cursor; this is a bit confusing since it could be interpreted as a vertical bar character
4. Line 504: "support wider range" should be "support a wider range"

Synopsis:

In this manuscript, Gan and coauthors outline a novel piece of cyber infrastructure that they have devised to support data/model assimilation for Earth-surface processes research. They demonstrate the overall structure of their cyber infrastructure they place it in the context of previous work at CSDMS. They demonstrate its scientific value with four case studies.

Overall Comments:

I found this manuscript nice to read, easy to understand, and broad in its impact and scope. I think that the major components that the authors highlight here have been well explained. The authors compellingly demonstrate how their new tool will accelerate geoscience research. 

After viewing some of the example notebooks, and attempting to set them up myself on a local machine, I ran into a few installation and software problems. I think these problems are simply software bugs and may be related to a changing API. They are not important to resolve here, and are best addressed through github issues. 

I do have a few (very) minor language suggestions:

lines [468-477] it's not totally clear to me in this section what parts have been implemented, and what parts Remain the implemented. For example, you state that it "will improve the usability of data components by extending the BMI standard". Have you done so? Or does that remain to be done? It would be nice to just be completely explicit here; the language is a little bit ambiguous.

Lines [354-356] here I think the sentence that begins with " with the trend of global warming..." needs a little bit of a rewrite, there are some mismatches between subject and verb that make it hard to parse.

 In any case, I recommend that it be published. 

I encourage the authors to get in contact with me if they have any questions about this review.

eric.barefoot@ucr.edu