dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction A principal challenge in paleoseismic research is having complete and properly time-constrained paleoearthquake catalogues. The presence of large sedimentary hiatuses due to depositional intermittency, imbalanced erosion-deposition rates or scarce availability of datable material are common limitations leading to poor age control in trenches. These uncertainties in the event age constraints add to the difficulty of site correlations and hence in establishing a reliable paleoearthquake chronology representative of the whole fault. To assess the correlation problem, two approaches have been developed (Fig. 1 ). The first one (DuRoss et al. 2011) addressed    this issue in a segment of the Wasatch Fault (United States) by correlating site chronologies computed with the Bayesian modelling software OxCal  (Bronk Ramsey, 2009 , 1995).
On top of this, both methodologies are developed for case-specific needs, so their applicability to other settings might be diminished, especially where paleoseismic data is less well-constrained and scarcer than for the tested faults. To accommodate the mentioned limitations, we present a new approach and accompanying code named PEACH (Paleoseismic EArthquake Chronologies). Its main purpose is to probabilistically compute paleoearthquake chronologies in faults based on an objective and unrestricted correlation of paleoseismic data, accounting for common problematic situations inherent to paleodata and reducing uncertainties related to event age constraints. This makes it flexible in terms of its applicability to other datasets worldwide. PEACH relies on i) simple and easy to compile inputs, including the option of using chronologies computed with OxCal, ii) a semi-automated workflow, and iii) outputs that can be further used to compute fault parameters for the hazard (e.
Fundaments of the approach It can be assumed that, because earthquake ruptures can be recorded at more than one site of a fault, it should be possible to identify correlations in paleoearthquakes between trenches along that fault. Furthermore, the differences in time constraints from site to site can help to better constrain the final event chronologies representative for the whole fault (e. g. ,  DuRoss et al. , 2011). Based on this assumption, the approach adopted herein is based on two main premises: a) Correlations are restricted to the fault level, defined as in the Fault2SHA Central Apennines Database (CAD)  (Faure Walker et al. , 2021). According to that, a fault is a singular first-order structure that has the potential of rupturing the entirety of its length and with prominent end boundaries that can cause ruptures to stop.
Data and workflow PEACH is based on a code written in MATLAB (https://www. mathworks. com) that probabilistically models event times from paleoseismic data on a fault to derive its paleoearthquake chronology. Such data needs to be compiled into a series of inputs detailed below. The current version (version 1) of the code is available at the Zenodo repository of the article  (Gómez-Novell et al. , 2023).
Input data The PEACH code relies on two simple input files. The first file (e. g. , faultname. csv; Table  1A ) contains a list of all paleoearthquakes classified by each site in the fault and the dates limiting its younger and older age bounds. The dates correspond to the calibrated numerical dates that limit the event horizons in the trenches (Fig. 2a ). The second file (site specifications, site_specs. txt; Table  1B ) specifies a series of calculation information (e. g. , sigma level truncation or number of random samples/seed) and allows the oldest and youngest dates for the exposed stratigraphy in each fault to be set in case these are not available in the datasets. Otherwise, if there are no dates missing in the dataset, the mentioned fields should state "nan". The "seed" is the number of samples that the code iterates in each limiting numerical date to compute the event PDF (see text for details).
All mentioned parameters except for the truncation level are skipped by the code when working with OxCal chronologies as inputs. 1A. Note that the insufficient date availability in site A, limit the capability of constraining individually the dates of events a4 to a2; all three events have the same age limits (Fig. 2e ). CW: Colluvial wedge. b) Conversion of the numerical dates and 1σ uncertainties of the input table  (Table 1A  for fault R with the mean value (dot) indicated for each PDF. Note that, because events E2 and E3 cover a time span where three events have the same age constraints in site A, there are two mutually exclusive hypotheses of event count that are provided for each PDF: if one hypothesis considers E2 as being one event, then E3 should correspond to two events and vice versa.
OxCal paleoearthquake chronologies Nowadays, most paleoseismic studies use OxCal to compute site chronologies because it not only allows the user to statistically model complex stratigraphic sequences with sometimes conflicting numerical date distributions, but also because it allows to impose a series of conditions to date events based on expert geological observations. That is, for instance, skewing the event PDF towards a limiting date due to the presence of coseismic evidence (e. g. , colluvial wedges). To allow the preservation of such expert rationales for the correlation, our code also accepts event PDFs computed and exported from OxCal, instead of the previously explained input. To do so, the PDFs of all sites expressed as probabilities versus time need to be provided in a single input file following a similar format to the one provided by OxCal.
I) Building individual event PDFs The individual event PDFs (event PDFs from now on) are built from the trench numerical dates that limit each event horizon (Fig. 2c ). First, the numerical dates are transformed into normal PDFs. Second, for each pair of numerical dates that limit an event, a random sampling of "n" iterations is performed based on the event probabilities and "n" time ranges are established between sample pairs (Fig. 2c ). The number of random samples (seed in the site specifications file; Table  1B ) is set at 4000 here by after a sensitivity analysis (Fig. 3 ). For the datasets tested in this paper (the synthetic example of table 1A and the Paganica Fault in Central Italy; Table  2 ), this seed ensures a robust and stable PDF modelling in several code runs and implies minor changes in the computed average PDF probabilities with respect to larger seed increases (see figure  3 ).
However, for some datasets the prominence threshold might require re-adapting, so smaller thresholds can be referenced manually in the code (see user manual;  Gómez-Novell et al. , 2023). Datasets with known historical or instrumental ruptures can also fall in the underdetection problem. These events have no timing uncertainties and, therefore, their peak probability equals one. Conversely, paleoseismic datasets have larger uncertainties and therefore much smaller peak probabilities in the order of 1•10 -2 to 1•10 -3 or less (e. g. , Fig. 2d ). The combination of both types of datasets in a calculation, generates a mean distribution whose shape is controlled by these historical peaks, while the paleoseismic show practically negligible prominences. This scale contrast flattens the normalized mean distribution in the regions where event PDFs have small prominences (poorly constrained; usually the older parts of the records), and thus can go unnoticed by the code given the minprom threshold set.
In such cases and if the target is to increase resolution of the older paleoseismic record, we recommend leaving historical events out of the computation. d) Event PDFs with wide codas. In such instances, the lower probabilities (close to 0) of the coda regions might interfere in the computation of the product PDF by over-constraining them compared to the original datasets. In addition to the overconstraining, the wide codas of PDFs can cause an incorrect clearance of the over-detection because they can intersect peaks located farther in time from their higher probability region. As the example in figure  4 : two close peaks detected in two jags of the same high in the mean distribution correspond to the same event, only that one of them is redundant. Because they are so close in time, in ideal conditions they will intersect the same event PDFs and yield the same final product PDFs, making it easy for the code to clear out the repeated event.
The recurrence and CV values, estimated arithmetically from inter-event times, are intended to be indicative and should be taken with caution, especially because some datasets might have completeness issues in the older parts of the sequences that can highly impact their reliability. For a more statistically robust computation and treatment of the uncertainties in the recurrence and CV, we recommend using the outputs of PEACH in other softwares such as FiSH  (Pace et al. , 2016) , which are specifically designed for this purpose.
Applications to real cases We show the application of PEACH in two datasets from two different tectonic contexts worldwide: the Paganica Fault in Central Italy (Fig. 5 ) and the Weber Segment of the Wasatch Fault System in the United States (Fig. 6 ). These faults are selected because they are well studied at multiple sites along their traces and, consequently, have populated paleoseismic records that are optimal to put the method at test. Furthermore, the fact that paleoseismic studies in the Wasatch Fault System have relied on OxCal modelling enables us to show the results of the approach also using such chronologies as inputs. Conversely, the artificial example shown in figure  2  demonstrates how the methodology is also able to work in simpler and less populated datasets.
Paganica Fault The Paganica Fault is an active normal fault accommodating NE-SW extension in the Central Apennines (Italy) and responsible for the devastating 2009 L'Aquila earthquake sequence, as demonstrated by seismicity (e. g. ,  Chiarabba et al. , 2009)  and coseismic surface data (e. g. ,  Falcucci et al. , 2009; Boncio et al. , 2010; Roberts et al. , 2010). The Paganica Fault used in this example is the one defined in the CAD database (fault level; Faure  Walker et al. , 2021) , composed of nine traces all of which demonstrated the capability of rupturing simultaneously during the 2009 event. The fault level considers first-order structures that can rupture entirely, but with prominent end boundaries able to stop ruptures from propagating further. We compiled the published paleoseismic data from the eleven paleoseismic sites (Table  2 ) studied along the Paganica Fault, with a total of 25 paleoearthquakes defined by the numerical dates limiting each event horizon (Table  2 ).
Two additional paleoseismic sites (Trench 3 by  Galli et al. , 2011 and Trench C by Moro et al. , 2013)  have been excluded from this analysis due to the lack of numerical dates to establish a paleoearthquake chronology. The compilation of the paleoseismic data implied a bibliographic revision in which we re-defined the age constraints of the 300 events in those cases where the authors introduced expert judgments (e. g. , assign a discrete historical date to an event based events because of their considerable overlap (>50% of the range of the event in TB). That is, in fact, the interpretation by Cinti et al. (  2021 ) using the same dataset as ours: two penultimate events at 1461/1703 CE (equivalent to our E5) and another one at 950/1050 CE (equivalent to our E3). The PDF of the last event at the TRET site allows us to identify also E4.
, 1991; DuRoss et al. , 2016; Valentini et al. , 2020). Based on this data, in the Wasatch Fault Zone we can confidently correlate data only within the primary segments, those based on the most prominent, first-order segment boundaries, where ruptures are believed to stop most frequently  (DuRoss et al. 2016). The primary segment concept in the Wasatch Fault Zone is equivalent the fault level used to define the Paganica Fault in the CAD database  (Faure Walker et al. , 2021). We select the Weber Segment because it is where the first approach to objectively correlate multi-site paleoearthquake chronologies was implemented  (DuRoss et al. , 2011). Hence, it is a good opportunity to test and compare our results. We recomputed the OxCal paleoearthquake chronologies from four paleoseismic sites in the Weber Segment using the OxCal models (scripts) performed and discussed by  DuRoss et al.
(2011) , which are available in their Supplements: Rice Creek (RC), Garner Canyon (GC), East Ogden (EO) and Kaysville (K). These models depict a total paleoearthquake record of 17 events is recorded throughout all sites for the past 7-8 ka BP. The input file with the computed OxCal PDFs used for our calculations is available at the Zenodo repository of this paper  (Gómez-Novell et al. , 2023).
Hereby, a similar scenario can be discussed for E4 at RC, although it would require further analysis with PEACH using the paleoseismic datasets of both segments. Another difference in our modelling results is that the uncertainties associated with E2 are considerably reduced compared to those estimated by  DuRoss et al. (2011) (Figs. 6c and 6d). That is because, for this event,  DuRoss et al. (2011)  compute the mean instead of the product PDF as they debate that the poor PDF overlap of the penultimate events in all sites would result in overconstraining. In the PEACH approach instead, the product of PDFs constrains the event in the overlapping area of all PDFs that is, in fact, where the event is most likely to have happened. More so, the shape and uncertainties of the product PDF are comparable to the better-constrained event at that time position (penultimate event at RC site; Fig.
In terms of event count, our approach strongly relies on the peaks detected in the mean distribution  (Figs. 4, 5b and 6b). That is, the peak prominence threshold (minprom) has a high impact on the number of peaks that are detected and therefore on the final number of events in the chronology. As the prominence threshold is dependent on the probabilities of the data themselves (Equation  1 ) and the final shape of the mean distribution, we cannot discard that for some datasets incorrect peak detections could appear. This includes both overdetection and underdetection. The code has several refinements implemented to solve these situations (noisy cluster clearance, sigma truncation, etc. ; see section 3. 2. 1), but even when all of them work properly, we strongly recommend the end-user to check that the number of events in the final chronology is coherent with the site data.
One way to check this could be comparing the event count with the cumulative deformation observed in the trenches, i. e. , evaluating whether the number of events is too large or too small to explain the observed deformation. Along this line of reasoning, we clarify that the universality of the approach to all datasets cannot be guaranteed. With PEACH we highlight how the correlation of paleoseismic datasets with different event completeness degrees and age constraining quality improves the detection of paleoearthquakes and reduces the uncertainties in event timing. By extension, it can potentially reduce the uncertainties in fault parameter estimates like average recurrence intervals or behavior indicators like the coefficient of variation. Also, the number of events correlated per site and time, compared to their location along the fault trace can give insight on fault rupture length (e.
Data and code availability The current version of PEACH (version 1) is available from the GitHub repository: https://github. com/octavigomez/PEACH under the license CC-BY-NC 4. 0 (https://creativecommons. org/licenses/by-nc/4. 0/deed. es). The exact version of the model used to produce the results used in this paper is archived on Zenodo  (Gómez-Novell et al. , 2023)  as are input data and scripts to run the model and produce the plots for the fault examples presented in this paper. This archive also contains the user manual with extended information of the approach and a step-by-step guide on how to use the code. Subsequent updates and releases of the code will be posted on GitHub.
Acknowledgments We thank  Yann Klinger ,  Paolo Boncio  and  Alessio Testa  for sharing data to test our approach and for their useful insights during its development. We also thank the MATLAB user community online for sharing their issues and ideas on the forums (Stack Overflow, MATLAB Answers) as they have provided us solutions for the development of the code. This work has been supported by two consecutive postdoctoral grants awarded to Octavi Gómez-Novell in 2022: " Borsa di  studio n. 2341/2021" funded by the  INGEO Department (Università degli Studi "G. d'Annunzio" di Chieti e Pescara)  and " Ayudas Margarita Salas para la formación de jóvenes   doctores 2022 " awarded by the  University of Barcelona  and funded by the  Spanish Ministry of Universities  with the  EU "Next Generation" and  " Plan de recuperación, transformación y resiliencia" programs.
5c ), based mainly on the correlation with the older events in T2_Ga and TA sites (Fig. 5a ). Although its timing is coherent with the data, its real uncertainty should be considered higher towards BCE times. For this same reason, in the BCE our method is not able to extract a chronology because the wide uncertainties generate poor definition in the average distribution for the peak identification (Fig. 5b ). Moreover, the fact that the Paganica Fault dataset includes the 2009 event changes the shape (prominences) of the mean distribution and likely reduces even more the code's capability to detect events in the older part of the sequence. This is because the 2009 event has no uncertainty and therefore, its probability is maximum (equal to one), as opposed to the much lower probabilities generated by older events (Fig.
The chronologies significantly reduce the uncertainties in the event timing compared to the original data (more than 50% in the cases exemplified). In addition, the probabilistic treatment of the event times along with a non-restricted site correlation of events seems to perform better in the event detection, allowing an increased total count compared to the trench observations. This can be observed in both cases we exemplify at the Paganica Fault in Central Italy and the Weber Segment in the Wasatch Fault Zone (Figs. 5  and 6 ) and is a coherent outcome for paleoseismic data, where events evident in trenches are always a minimum relative to the actual number of events that occurred. Another strong advantage of our method is that it does not rely on strong expert judgments in the event computation nor the correlation.
In detail, first, the event PDFs are built considering only the age constraints provided in the input, which should presumably correspond to numerical dates independently dated. That is, the shape of the event PDF (skewness, width and height) exclusively depends on the shape of the date PDFs that limit it. Second, the correlation is done independently of the event PDFs involved, meaning that all PDFs that contribute to a peak in the mean distribution and thus, that intersect it, are integrated to compute the final PDF of that event. This removes a layer of expert judgment introduced when correlating only between PDF pairs, like DuRoss et al. (  2011 ), which we suggest could eventually decrease the capability of detecting additional events in the dataset (e. g. , smaller events not recorded in all sites).
the calculation with PEACH. Notes: A) Main input file containing the paleoseismic events and limiting dates for the example of Fault R in figure 2a (file faultR. csv in the "Inputs" folder at the code's Zenodo repository; Gómez-Novell et al. , 2023). Events are sorted from youngest to oldest in each site and the dates (and corresponding samples in brackets) represent the age of the units limiting the event horizon in the trenches: "Event_date_old" is its older constraint and "Event_date_young" its younger age constraint. Error columns represent the 1σ uncertainties of the numerical dates. Dates should be provided with the BCE/CE notation: negative for BCE and positive for CE. "Null" means not available. B) Example of the site specifications file of fault R in figure 2 (site_specs. txt in the "Inputs" folder).
)  [34]. The gateway transmits the data to a server via the Internet network, providing a bridge between the nodes (connected to the LoRaWAN network) and the server (connected to the Internet network). 2. 2. Node SoLo (Sensors Open Lora Node) 2. 2. 1. General Presentation of the Node Due to the large variety of sites addressed by the present project and envisaged by future projects, as well as the number of different sensors deployed in the environmental sites, a generic LoRaWAN end node, named SoLo, has been developed. This node has been designed to allow data reading from a large variety of associated sensors, and it can be configured at the hardware and firmware levels to be adapted to the specific needs of measurements, autonomy, data processing, and data transmission. The hardware architecture of this node is given in Figure  3.
Sensors 2023, 23, x FOR PEER REVIEW 4 of 25 variation of frequency over time. This technology allows communication over long distances (several kilometers)  [32]  at low power (maximum effective isotropic radiated power of 40 mW in Europe)  [33]  but with a limited communication rate (50 kbps max. )  [34]. The gateway transmits the data to a server via the Internet network, providing a bridge between the nodes (connected to the LoRaWAN network) and the server (connected to the Internet network).
Node SoLo (Sensors Open Lora Node) 2. 2. 1. General Presentation of the Node Due to the large variety of sites addressed by the present project and envisaged by future projects, as well as the number of different sensors deployed in the environmental sites, a generic LoRaWAN end node, named SoLo, has been developed. This node has been designed to allow data reading from a large variety of associated sensors, and it can be configured at the hardware and firmware levels to be adapted to the specific needs of measurements, autonomy, data processing, and data transmission. The hardware architecture of this node is given in Figure  3. The SoLo node is built around an STM32 microcontroller  [35] , which controls all the operations thanks to embedded firmware developed in C and C++ languages. Each node has an internal SD memory to store sensor data, the history of the actions of the node (log file), and the configuration file.
This configuration file, which is read by the microcontroller at start-up, is defined by the user and lists the configuration parameters of the node. A LoRa RF module is implemented on the electronic board to send data through the private LoRaWAN network. A GPS module has also been added to localize the sensor and to deliver a timing reference to the system. The power supply is delivered by a 3. 6 V/9000 mAh battery cell managed by a charge controller circuit. The SoLo node also integrates a small electronic card on which several sensors are implemented. These internal sensors can be activated or not. They measure temperature, air humidity, atmospheric pressure, luminosity, and acceleration. Several protocols of communication are implemented to communicate with external sensors: UART, SPI, SDI-12, I2C, analog and digital IO.