Response to Reviewers

Dear Reviewer,

We appreciate the time and effort that you have dedicated and are grateful for your insightful comments which have improved

the manuscript. We have incorporated the constructive suggestions, and have highlighted the changes within the manuscript

and marked them in blue color. Here is a point-by-point response to your comments and concerns.

Reviewer 1

In this work, the authors apply the dynamic convolutional neural network to two tasks: seismic phase classification and arrival-

time picking. They compared the new model, DynaPicker, to a few other deep learning models and demonstrated that Dy-

naPicker could achieve better performance for input data of different lengths. The main concern I have for this work is that

the model comparison may not be very accurate. The reported improvements in precision/recall/F1 scores are not significant,

so the performance of DynaPicker may become even worse if choosing a slightly different threshold. Based on the selected

examples shown in the paper, the false positive rate of the new model could be very high. I would request the authors to

plot precision-recall curves to compare the performance of different models to avoid bias in selecting a specific threshold for

comparison. One good example is Münchmeyer et al.’s work of "Which Picker Fits My Data?”

Response: We thank the reviewer for the constructive suggestion.

– Following Münchmeyer et al.’s work “Which Picker Fits My Data?”, we have plotted the receiver operating characteristic

(ROC) curves for the DynaPicker and GPD models as follows. Based on Figure 1 (see attachment), it’s evident that DynaPicker exhibits

a similar low false positive rate to the GPD model. Furthermore, the picking error distribution summarized in Tables 4

and 5 that DynaPicker performs better in phase arrival time picking than GPD.

– Unfortunately, even with our multiple attempts, the CapsPhase model retrieved from the git repository cannot be utilized

at this time. When loading the CapsPhase model in the created virtual environment, we received a segmentation fault

error, even after increasing the memory size. We will keep on trying to perform the comparison with the CapsPhase

model and will address this in our follow-up work.

1. Table 4: I have three comments of the reported results: (1) Based on the standard deviations of the time residuals, we can

see clearly DynaPicker has a very large time error for both P and S phases. I am wondering if DynaPicker is really an improved

alternative to current models. (2) In the table, only the number of picks (< 0.5s) is reported. But how many picks (> 0.5s) does

DynaPicker detected? It is important to report the false positives. (3) The absolute number of undetected events is not helpful.

What activation threshold do you use? How many false positive events do you detected in order to detect all true events?

Response:

– Here we followed the CapsPhase work definition i.e., ’if the error between the model’s predicted picks and the ground

truth picks have an absolute error below 0.5s, then it is true positive’. As indicated in Table 4, the time residuals of Dy-

naPicker exhibit standard deviations that are either similar to or smaller than those of other models. In certain instances,

DynaPicker even surpasses the other models by having lower standard deviations.

– In Table 4, a total number of 10,000 events for each scenario are randomly selected from the STEAD dataset. All of these

earthquake events are correctly detected using DynaPicker. In case 1 (used model: DynaPicker), there are 945 events with

P-phase picking errors exceeding 0.5s and 2304 events with S-phase picking errors exceeding 0.5s, respectively. In case

2 (used model: GPD), there are 2595 events with P-phase picking error and 2403 events with S-phase picking error

greater than 0.5s, respectively. In both Tables 4 and 5, we have introduced two additional columns to denote the number

of picks exceeding 0.5s for both P- and S-phases as shown in the following tables.

– In the task of the seismic phase classification with the SCEDC dataset, we did not use any activation threshold for

event detection. However, in the context of analyzing the aftershock sequence of the Turkey earthquake, we empirically

established an activation threshold of 0.7 for detecting events. We would further like to point out that the threshold

should indeed be chosen carefully by the user based on the station and the data and what we show here is an example.

The threshold of 0.7 was chosen experimentally to get the most optimum balance between false positives and false

negatives.

Changes in manuscript: We have updated Tables 4 and 5 in the manuscript. Line 78-80 are added

2. Fig. 2: I am confused by this plot. If the predicted scores are also pretty high for waveforms that are not P or S phases,

there could be many false positives. Based on the examples shown in Fig. 5, we can see DynaPicker can also easily pick up

false positives.

Response: Figure 2 provides a schematic representation of the arrival time picking process for continuous seismic data,

employing various window sizes while processing the same continuous waveform. Even though the probability might be rela-

tively high (> 0.7) in few other windows, we opt for the window with the highest P/S probability, which usually is in the order

of 0.99, to estimate the phase arrival time. As illustrated in the initial ROC curves, by following this approach, DynaPicker

exhibits a minimal number of false positives.

3. Eq. 5: Did you compare the results using T = 1 and T = 4 for the phase picking problem? Because the temperature softmax

function is not used by previous works of phase picking, it is necessary to demonstrate that it can help the phase picking task.

Response: We concur with this observation of the reviewer. We have summarized the outcomes of utilizing different tem-

peratures for phase picking in the Appendix. The relevant table is presented below. You can find this table on page 22 of the

manuscript.

4. L230: "we can observe that EPick achieves the best performance in phase picking over DynaPicker by using different

window sizes." Does this mean the claimed advantage of DynaPicker for different input length is not true? Although you

explain that the reason is that EPick is pre-trained using the STEAD dataset, you can also train DynaPicker using the STEAD

dataset to make the comparison more accurate.

Response: In response to the reviewer’s recommendation, we proceeded to retrain the EPick model using the same dataset

sourced from the STEAD data, which serves as the training data for DynaPicker. Subsequently, we employed the retrained

EPick model to estimate phase arrival times for continuous data extracted from the STEAD dataset. It is important to highlight

that there is no overlap between the datasets used for EPick training and those utilized for phase arrival time detection. We

observed that, while the performance in detecting the P phase was similar, the accuracy of S-Phase picking decreased from a

mean value of -0.002s to -0.050s, and the standard deviation increased from 0.122s to 0.147s. Additionally, The EPick model

is developed for the task of estimating seismic phase arrival times with fixed input length. In contrast, the DynaPicker model

was primarily designed for phase classification and its adaptation for phase arrival time detection with different input lengths

is a notable application. Furthermore, as the size of the training data increased, DynaPicker exhibited improved performance

and demonstrated greater robustness when compared to EPick.

Changes in manuscript: Texts updated to help readers understand the process on pages 11 and 12.

5. L240: "The testing accuracy of DynaPicker is 98.82%, which is slightly greater than CapsPhase [30] (98.66%) and 1D-

ResNet [9] (98.66%)." Because the differences are very small and do not tell readers much information, could you compare

the waveforms of false predictions of these models to help understand where DynaPicker can be better?

Response: As per reviewer’s suggestion, here, we plot several waveforms of false predictions, while they are correctly

identified by DynaPicker.

Figure 2. Visualization of trace examples.

From these figures, we can observe that compared with other models, DynaPicker shows its advantage in phase classification.

in scenarios where the ground truth label is noise and the seismic waveform exhibits increased noise levels, DynaPicker

accurately identifies it as noise, whereas the GPD and ResNet models tend to misclassify it. Unfortunately, as mentioned

before, the CapsPhase model retrieved from the git repository cannot be utilized at this time.

Response to Reviewers

Dear Reviewer 2,

We appreciate the time and effort that you have dedicated and are grateful for your insightful comments which have improved

the manuscript. We have incorporated the constructive suggestions, and have highlighted the changes within the manuscript

and marked them in blue color. Here is a point-by-point response to your comments and concerns.

Reviewer 2

The manuscript proposes a new deep-learning picker that leverages dynamic convolutional neural networks for detecting and

picking seismic phases from windowed or continuous waveform data. The authors then combined the previously published CREIME model for magnitude estimations of waveform windows that have high P-wave probabilities. The authors have evaluated the performance of their picker and their combined workflow on open-source seismic datasets and aftershocks following

the Turkey earthquake. The technical part of the manuscript is overall solid. However, I have vital concerns about the ‘real-time’ claim. It seems to me that the authors have confused the concept of processing continuous data with the concept of real-time earthquake monitoring. I suggest the authors modify their claim from ‘Real-time’ to ‘efficient’ and emphasize more on the

performance of the proposed deep-learning picker. Aside from the ‘real-time’ claim, the study seems good overall. Below are our detailed comments:

Response: We appreciate the reviewer’s suggestion to modify our claim from ’real-time’ to ’efficient’. We understand that

’real-time’ can have different interpretations, and we agree that emphasizing the efficiency of our proposed deep-learning

picker is essential. We made this adjustment in the revised manuscript avoiding the strict interpretation of ‘real-time’.

1.How is the term ‘Real-time’ defined? What is the time cost between the time of data recorded at the seismometer and the

time of output produced? Please note that there are several important steps for real-time earthquake monitoring besides the

time cost of the phase-picking model. For example, how is the time cost of the data transmitted from the seismometer to the

data center? Is the data processed at the seismometer end with edge-computing (which would be important in areas with poor

internet access), or is the data transmitted to the data center first and processed later there? The data packages in the real-time

seismic data flow can contain errors due to transmission issues. How is that addressed?

Response: We acknowledge that the term ‘real-time’ to describe our model’s performance was a misnomer. Our model does

not operate in real-time, and therefore, we did not perform any analysis on the time cost of real-time data flow. We apologize

for any confusion caused by the incorrect terminology and thank the reviewer for pointing this out. Instead, our proposed model

provides timely results from continuous waveform recordings. We revised the manuscript to accurately reflect this and ensure

that our terminology aligns with the actual capabilities of our model.

2.What is the inference time cost of the model? What is the key advantage of the proposed method over conventional

and lightweight convolutional deep-learning pickers in terms of real-time monitoring? The authors claim, "However, most

of the prevalent CNN-based models perform inference using static convolution kernels, which may limit their representation

power, efficiency, and ability for interpretation.” However, to my acknowledgment, the current CNN-based models, especially

lightweight ones, are sufficient for millisecond-level inference. One key claim of the manuscript is that the proposed method is

much faster and, therefore, more suitable for real-time earthquake monitoring. However, I didn’t find any quantitative compar-

isons on the inference speed in this paper.

Response: In the introduction section of the manuscript, we claim that “However, most of the prevalent CNN-based models

perform inference using static convolution kernels, which may limit their representation power, efficiency, and ability for in-

terpretation.” To clarify, our primary focus in this work is the utilization of the dynamic networks to enhance the performance

of the seismic phase classification performance and, consequently reduce the errors in the phase arrival-time estimation. As

a result, we have not quantified the time comparison of the inference speed in this paper. However, following the reviewer’s

suggestion, we will explore such a relative comparison in our follow-up work.

3.The event’s location is one key information in earthquake monitoring and yet not resolved by the current workflow. The

lack of event location information would decrease the significance of the proposed monitoring method.

Response: Event location is indeed a crucial component of seismic analysis, but its inclusion in our current model was

beyond the scope of this work. We understand the importance of this aspect and recognize it as an essential feature for a

comprehensive seismic monitoring system. However, getting an accurate phase arrival is crucial for a correct event location

determination. We plan to address event location information and upgrade the current model in future research.

4.Why is being adaptive to different input lengths important? Is that because in the real-time earthquake monitoring scenario

that the authors are dealing with, the input lengths of data chunks can be significantly different? And what are the advantages

of the proposed method over the RNN-based pickers, which can also adapt to different input lengths?

Response:

– The proposed method is adaptive to different input lengths, as it can accommodate the continuous data of different

durations. We have edited the text in line 40 to highlight this.

– We are currently working on a RNN-based model for event detection which will be a follow-up of this work.

25. Section 5.5 ‘Real-time earthquake detection’, how is the ‘real-time’ here different from ‘continuous data’? Section 6.2

‘the live data of the Turkey earthquake’, what does the ‘live data’ mean, do authors have access to the real-time data packages

from the Earthquake Data Center System of Turkey, or do they use the downloaded continuous waveform data?

Response: We incorrectly used the term ‘real-time’ when referring to our data source. we apologize again for the inconve-

nience. To accurately describe our data source, we now use the term ‘continuous seismic recordings’ throughout the revised

manuscript. This term better reflects the downloaded continuous waveform data that we are utilizing.