The manuscript “Observing atmospheric convection with dual-scanning lidars” by Duscha et al. introduces a lidar measurement and data processing approach for the observation of atmospheric convection. Principles of the introduced approach were tested in two experimental campaigns, allowing for the conclusion that the approach is suitable for the defined objective.

The manuscript is generally well written and describes both the proposed methodology and the obtained results in more than sufficient detail. Stating this, however, I have found two major points of critique which should be addressed for the manuscript to be acceptable for publication:

1. The (final) measurement approach is proposed as being optimal for the objective. This is described in much detail but, I think, it would be very helpful to also introduce a clear set of criteria the evaluations of which allows this conclusion. I understand that a verification is very difficult but I wounder if the authors can find some other performance criteria that may underline the superiority of the methodology.

In addition to this, the wording may be adjusted at some points in the text: only in l. 420 the study is referred to as “proof-of-concept”, for instance. In the abstract (l. 7) it says the setup was “tested” but it is unclear here if this is already a demonstration. Maybe “proof-of-concept” is also a better term here – however, it should be clarified then if the used parameters (lidar settings) are considered already an optimal solution which should be recommended also for future studies of this style.  

Answer: See  answers to minor comments

1. The structure is in my opinion not sufficiently clear. Some sub-sections may be introduced better or re-arranged – see my following comments for some suggestions.

Answer: Thank you very much for your suggestions, we edited the manuscript, based on your comments as follows:

Minor comments (in order of their appearance in manuscript):

(l. 3)       It is not clear to me what the “novel [..] approach” comprises – e.g., using two scanning lidars, their scan strategies, detailed timing of scans, data filtering, and/or reconstruction. This should be further specified not least to justify the term “novel”.

(l. 7)      Here it is not clear what “tested” really means – e.g., demonstration, verification or just proof-of-concept.

(l. 8)       What are the two (“both”) pre-processing procedures referred to here?

(l. 20)    Not sure I understand what “resort” here means. Please be more specific.

(Introduction – in general)          Generally, the Introduction could be better structure. In (l. 36) I’d propose to insert a “Here, .. [we propose]” but I also think that literature review and components of new study are too much mixed – so better move this sentence to another place.

Answer: Here, we put our study into the perspective of past studies to highlight what is new in the study compared to previous work. Hence, we would like to keep this sentence in its original place. The sentence also forms a bridge to the subsequent paragraph. To differentiate stronger between our own study and past studies, we begin the sentence with “In our study, […]” 

The last paragraph (starting l. 60) reads like a conclusion; instead, I’d propose to introduce the structure of the manuscript here.

(l. 62)    Should be “parametrization schemes” (no “s”).

(l. 67)    Introduce short intro text to section between section and sub-section heading.

(l. 117) Delete “a”.

Answer: Done 

(l. 121)  Delete “out”.

Answer: Done 

(l. 125) DBS scan was already mentioned above, so maybe no need to detail it again.

(l. 141) Add “in [Sect. 6]”.

(ll. 158) Also introduce sub-section (with their numbers) here.

(ll. 289) Also introduce sub-section (with their numbers) here.

(l. 335) I believe “1” and “2” should be indices/sub-scripts.

(ll. 362) Also introduce sub-section (with their numbers) here.

Answer: See comment above 

(ll. 415) Also introduce sub-section (with their numbers) here.

Answer: See comment above 

(Figure 6 -- caption)        “Diurnal”

Answer: Done 

(l. 568) I’d suggest to add “Discussion” to the section title.

This section is quite lengthy; I’d suggest to add a sub-structure / sub-sections levels to it.

(l. 685) Please specify here (again) what the proposed setup comprises – see my comment above.

The paper is overall well written and presents interesting results from dual-Doppler lidar scans in the convective boundary layer (CBL) at two different sites. The approach itself is not really novel per se but the authors tested different scanning and data processing strategies that allow improved resolution of flow structures and error quantification. I have two major concerns that resulted in my assessment that major revisions of the paper are needed:

• I am not convinced that the applied DBSCAN noise filtering technique is adequate. The example presented highlights, that the clustering favors the range of velocities that is to be expected in the CBL and then clusters a significant number of data points with low SNR values but filters out data points that would traditionally be considered to be good data. What is the justification for this? I am concerned that interesting features may be filtered out, while noisy data are being retained.

   

   

• Answer: The clustering of points below –27dB is desired as these points are not noise. We show that in Figure 4 and reflect on it in the corresponding discussion. Here, no noise is retained, as the points recovered below –27 dB follow the same radial velocity patterns as the surrounding non-noisy points above the –27dB threshold (see Figure 4a and d); Hence, they do not fall into the noisy category. The algorithm only filters out data points that are not dense in the scatter of vr against SNR, meaning, if SNR is higher overall, the cluster moves to high SNR values. This is for example the case for the observations at Vaksinen. The DBSCAN dynamically adjusts to the valid SNR and vr range. 

  Also, the filtering/ discarding of the points that are  scattered thin above - 27dB is desired. Conventional filters would consider these points above - 27dB as "good data". However, a substantial part of these points is not, as they correspond to erroneous features, such as range-folded ambiguities or obstacles on the ground. We show that noise and erroneous features are removed by the DBSCAN algorithm (Figure 4d), but not by the conventionally used SNR threshold filter (Figure 4c). We agree that some of the discarded points (above -27 dB) also correspond to data from within the highly reflective cloud that could be considered as good data. Additionally, there are some rarified scatterers above –27dB, which are classified as noise, but do not fall into the feature category. However, the overall data potentially "lost" here is smaller than 2% (cloud) and smaller than 3% (noise), which is much smaller than the gain of “good data” additionally recovered below -27 db (+48%) by the DBSCAN algorithm.  

  This recovered data covers the center of the convective circulation, while the cloud is only at the edge. The distinction between "discarded because of noisy" and "discarded because of potential erroneous features" was not highlighted by Figure 3 and 4. To clarify, we separated "noise and features" in the plot and in the corresponding caption (see attached supplement). Further development (e.g. machine learning) could probably even distinguish which of the features are desired and which not. As the desired features only make up a negligible part of the studied area, we decided that implementing such an additional distinction algorithm would exceed the scope of this study. 

  For the retrieval to work, it is critical to remove the points that correspond to erroneous features and large spatial patches of the noise. Figure 4 and the corresponding discussion show that this is achieved by the DBSCAN algorithm and not achieved by the conventional SNR threshold filter at the same time. Even if a small number of “good” points that are distributed throughout the cross-section are missing, the retrieval is not affected. The retrieval methodology also works even if some data points within the polar coordinate system are missing, as long as there are sufficient number of vr points from each lidar available within distance R from the cartesian retrieval grid point. As these two statements are not clearly communicated in the manuscript, despite their importance, we decided to follow the reviewer’s comment below and changed the order of Section 3 and 4 and include these statements to the radial velocity filter subsection.

  To conclude, only a negligible part of non-erroneous features (below 2%) or potentially wrongly classified noise (<3%) was discarded. Erroneous range-folded ambiguities and obstacles that strongly impact the quality of the retrieval were removed and no noise was retained, while a substantial part of good data below –27dB was recovered. We believe this justifies the usage of the DBSCAN algorithm. 

   

• The authors need to provide additional information about how they determined the values for the density radius
• Answer: The density radius and number of samples is dependent on the number of points in the analyzed section where the number of samples can be adjusted with the total number of points in the section. Keeping the density radius constant, the range of the number of samples that could be applied was rather wide. The criterium for choosing the combination of density radius and number of samples was that only one main cluster was identified. Any secondary cluster needed to be at least 3-density radius apart. We have included this explanation in the manuscript. 
• and number of samples and why the data points with SNR values >-27 DBZ with v_r~0   should all be considered noise.

   

   

• Answer: For the displayed example, not all data > -27 dB are considered as noise or features. Here, the cluster detected by DBSCAN also covers data > -27 dB, comprising 14% of the whole data, in contrast to 5% that were not within the cluster. The data remaining in the scan is sufficient to retrieve u and w velocity components on a cartesian grid (as the retrieval also considers all points within a certain radius around the grid point)  

   

• It also appears this filtering was only applied to the RHI scans but not to the DBS scans. If though, why is this the case?
• Answer: Thank you very much for pointing out that this information is missing in the manuscript. 

  Before the retrieval of the wind profile, the DBSCAN algorithm is also applied to the DBS scans. We apply the algorithm to the 10-minute series of each lidar beam individually with adjusted number of samples at constant density radius (see above), depending on the number of points (number of range gates times number of time steps). To retrieve the 3D wind profile, all values from the 10min intervals are also used (over constrained equation system, solved using least-squares). Since we use a composite of the 10-minute intervals it is not necessary to apply temporal interpolation. 

  We added this explanation to the radial velocity filtering subsection.  

• And, how does this type of filtering affect SNR based CBL height detection algorithms?

   

• Answer: SNR determines the quality of the radial velocity, but not the other way around (SNR is dependent on the laser’s properties and the aerosol concentration). The DBSCAN algorithm uses SNR to identify which points need to be filtered. However, the filtering is only applied to the radial velocity values and not the SNR values. Hence, the filtering does not affect the CBL height detection. The sub-section title specifies and also within the subsection we specify multiple times that we apply a filter to the “radial velocity”.  

• The data analysis and discussion of results included in the paper primarily just focuses on the detection of updrafts and downdrafts in the CBL. While the detection and tracking of these flow structures is interesting, the paper falls short in providing new insights about turbulence statistics in the CBL. Does the presented method really have the potential to provide new knowledge about physics in the CBL and data that can be used to evaluate parameterization schemes?

   

• Answer:  The main purpose of the paper was not to provide turbulence statistics in the CBL, but to demonstrate that the presented measurement and processing technique is capable of capturing convective circulations in time and space. The focus on demonstrating and evaluating the methodology is due to the choice of the journal “Atmospheric Measurement Techniques”. 

  The presented measurement and processing technique provides convective flow fields in time and space, which are not provided by any other state-of-the-art measurement techniques. Multidimensional flow fields to guide Parametrization schemes for convection are currently only provided by LES simulations, which also provide information about the convective flow field on a cartesian grid. Hence the observations provided by the proposed method and LES can be directly compared on multi-dimensional level. 

  Demonstrating and evaluating the capabilities of the technique (with some sneak peek into the meteorological implications found for two case studies) is the stepping stone towards designing more extensive field campaigns and developing further studies about detailed statistics of convection in the atmospheric boundary layer. Such statistics would also require a larger database as available here and exceed the scope of this manuscript and is therefore material for further studies. 

  We have specified these points in the Introduction (See next comment) and the Conclusion. As some of these points are more an Outlook, we renamed the “Conclusions” to "Conclusions and Outlook" 

   

A few additional minor comments:

P1,around l20: the discussion switches here from limitations of conventional  instrumentation to LES and then back to a need for better observations. The authors should expand and re-organize these points a bit and add more details about the modeling approaches for the CBL, where conventional observations have limitations, what gaps can be filled by LES, but where does LES fall short and we still have a need for new information.

Sections 2.3 and 3  could be better organized. I think the section would flow better if the authors first introduced the general strategy (section 4.1), and then addressed the different sources of errors and how they are addressed in their retrieval.

Sections 6.3 and 7 are rather long and could be shortened.