dataesr/scientific-paragraphs-categorization huggingface dataset:
Waveforms and station meta information At the heart of ASDF is the waveform data. A single file can store any number, combination and length of waveform data. Waveforms are restricted to single and double precision floating point and signed integer data and are stored as HDF5 native data arrays. These data arrays are logically grouped by using four codes: the network code denotes the operator of a seismological network, the station code denotes a station within that network, the location code denotes a particular instrument at a station, and finally the channel code denotes the recording component. These codes are often called SEED (Standard for the Exchange of Earthquake Data) compatible identifiers (Incorporated Research Institutions for Seismology (IRIS) 2012) and, together with some temporal information, allow the unique identification of seismic instruments and are also used in the QuakeML and StationXML standards.
ASDF organizes waveforms and associated meta information at a station level granularity. Other choices would have been possible, but this provides a certain balance between the necessary nesting and the number of elements per group (like a directory in HDF5 terms). Each station can optionally contain a StationXML document made up of meta information for one or more channels of that station. StationXML is the current FDSN standard for station (1, yellow) Information about an arbitrary number of earthquakes (or other seismic events) is stored in a single QuakeML document, the most complete earthquake description format currently available. (2, green) Seismic waveforms are stored per station together with the necessary meta information in the form of an FDSN StationXML document. (3, red) Anything that cannot be regarded as a seismic waveform is hierarchically stored in the auxiliary data section.
(4, blue) Provenance information is stored as a number of SEIS-PROV documents, an extension to W3C PROV. Background colours in the attributes (rectangular boxes) denote relations to other sections in an ASDF file. Examples of this are relations of a waveform to a certain event or a provenance record for a piece of auxiliary data. information and the successor of the SEED standard. Roughly speaking, it contains information about who runs a network and deployed the station, about the geographical and geological setting of the station, and the impulse response of each recording channel. This is vital information, and storing it alongside the actual waveform data eases many common undertakings. A StationXML document can contain as much or as little information as appropriate for any given task.
A further benefit is that StationXML can also be used to describe non-seismological time-series, such as pressure and temperature curves. The waveform data are stored as pieces of continuous, wellbehaved time-series data. Each piece, in the following called a trace, consists of a start time, a sampling rate, and a data array representing regularly sampled data. The starting time of each trace is internally represented as a nanosecond precision UNIX epoch time. The use of a 64-bit integer grants a temporal range from about the year 1680 to 2260, which is sufficient for all envisioned use cases. Times are always in UTC in accordance with most other seismological data and file formats. Every station can contain an arbitrary number of traces consisting of data from multiple locations and channels.
Incidentally, HDF5 supports reading portions of an array which enables users to read only portions of very long time-series within an ASDF file. Real world data is not perfect, and seismic receivers can fail and thus produce gaps or overlaps in data. Many existing file formats have no concept of this and thus require workarounds. In ASDF a gap is represented by one trace before and another trace after the gap and two overlapping traces denote an overlap. This construct has proven itself to work very well in practice and is also employed in the MiniSEED format as well as the ObsPy library. Last but not least, each trace potentially also carries some more meta information and relations to other places within an ASDF file. These are elaborated upon in a later section. ASDF's construction is not a perfect fit for active source exploration data, which is mainly a consequence of the chosen nesting structure and StationXML heavily leaning towards passive source and station based seismology.
C O M PA R I S O N T O E X I S T I N G F O R M AT S Having yet another format induces more complexity and, potentially, noise into the community using that type of data and the landscape of software able to deal with it. 'Do we really need a new format?' is thus a natural and understandable question. This sections addresses why no single existing data format in seismology is able to satisfy our needs and thus justifies the introduction of the ASDF format. We limit ourselves to detailing alternative waveform formats as we directly incorporate the StationXML and QuakeML formats and no true alternative to storing derived data or provenance is currently in existence. A wide variety of different seismological data formats is used by researchers world wide. We will discuss the most widely used ones, namely, (Mini)SEED, SAC, and SEG Y/PH5.
MiniSEED SEED was developed in the late 1980s and at least the data-only part (MiniSEED) continues to be in wide use today, and will likely continue to be the dominant data streaming and archival format for the foreseeable future. The ASDF format does not attempt to replace it. Some of MiniSEED's features, such as the ability to build up large data volumes by concatenating small and short pieces, are very well suited for their use in data archives, where data is constantly streamed in. While the full SEED format can in theory store waveforms as well as station meta information, the complexity of the format hinders that. It furthermore can only properly store raw waveform recordings and no event information. Additionally, the dataless part of SEED, e. g. , the part with the station information, sees declining usage nowadays with that responsibility being taken over by StationXML.
MiniSEED, on the other hand, is more than capable of storing arbitrarily large waveform volumes, but the file then contains no index of what is in it, so one must always read the entire file to figure that out, making large data volumes fairly impractical. Additionally, the amount of meta information in MiniSEED files is strongly limited, so one always needs additional files to work with it. Downloaded from https://academic. oup. com/gji/article/207/2/1003/2583765 by guest on 16 April 2022 ASDF 1009 Summing up, MiniSEED is a good data archival format for data centres, streaming and low-latency applications, but it is not well suited for the later research and processing stages, where ASDF has significant advantages.
SEG Y and PH5 The SEG Y Data Exchange Format (SEG Technical Standards Committee 2002) is one of many in the family of data formats introduced and defined by the Society of Exploration Geophysicists (SEG) Technical Standards Committee. Among these, it is probably the most widely known and used. The more modern PH5 (IRIS/PASSCAL Data Group 2012) format has a data model similar to SEG Y, but stores its data in an HDF5 container. This eliminates some limitations of the SEG Y format and facilitates more extensive meta information. It has been developed as an archiving format for active source seismic experiments. Typical workflows extract data from PH5 and save it as SEG Y, which is used in the further stages. Both on-and off-shore active source data is very structured, meaning that all receivers generally have the same response and record for the same time span with the same sampling rate.
In the use cases section we will show an example of how it can still be done. The concept of seismic sources and receivers nonetheless holds true in both active and passive source seismology. We have the hope that, in the future, ASDF will be used as a standard for both. Active source seismology currently lacks community accepted standards for sources and receivers as is common in passive source seismology with formats like QuakeML and StationXML. Methods, ideas, and techniques are frequently exchanged between these communities, and we encourage the development of these missing standards. A common data format would enable greater sharing of tools, whole workflows, and most importantly human knowledge and skill, greatly benefiting both sides. The ASDF format is ready to incorporate these aforementioned definitions.
I M P L E M E N TAT I O N S We developed three usable implementations of the ASDF format and expect more to follow: (i) A C library with Fortran bindings to read and write ASDF files. This is for example used in the SPECFEM3D_GLOBE  (Komatitsch & Tromp 2002a,b)  wave propagation solver. (ii) A Python library to read, write, and convert ASDF files to a large number of other formats backed by the ObsPy library  (Megies et al. 2011; Krischer et al. 2015). (iii) A graphical user interface to visually and interactively explore the contents of ASDF files. Technological advances often make existing codes and tools obsolete in a matter of just a few years, and we anticipate that these implementations will continue to undergo rapid development and expansion.
The small boxes above the columns denote the relative writing duration in red and the relative reading duration in green compared to the uncompressed case. The left plot shows the efficiency for a data set containing 500 StationXML documents adding up to 120 MiB. I/O speed differences are irrelevant as the cost for parsing and generation of the XML documents is constant and dominates the total run time. The middle plot shows the compression efficiency for a bandpass filtered waveform data set stored as 32-bit floating point numbers. It consists of 3466 waveform traces taking up 282 MiB on disk. The red bar compares it to the uncompressed SAC format. The rightmost plot shows the efficiency for storing 3346 raw waveform files stored as 32-bit integers taking up 2340 MiB. The red bars here show the efficiency for the same data set of the STEIM1 and STEIM2 special purpose compression algorithms defined for the SEED format measured by writing them as MiniSEED files.
2005; Fichtner et al. 2006; Tape et al. 2010 ), but the general concepts translate to other types of workflows using large amounts of data. This iterative procedure requires routine comparison of millions of waveform traces. We replaced an implementation based on the SAC package and file format  (Helffrich et al. 2013 ) with an ASDF centred implementation. The SPECFEM3D_GLOBE waveform solver  (Komatitsch & Tromp 2002a,b)  directly produces ASDF files which are then tied into a single cohesive workflow relying on the ObsPy  (Beyreuther et al. 2010)  package. All components integrate with each other and stream data from one unit to the next. I/O only happens at the very beginning and the end. These changes empower us to increase the scale of our inversions-in terms of frequency content, number of earthquakes and number of stations-and fully exploit modern computational platforms.
Active source industry data set Industry data sets are not the primary focus of the ASDF format, but it is worthwhile proposing how we could adapt the format to that particular case in an effort to bring the active and passive communities closer together. Active source data is more structured and array like, both in sources and receivers. As the industry currently lacks standards to describe these, we utilized the QuakeML and StationXML formats with some extensions to for example share the array configuration and source time functions. Waveforms are grouped by recording instrument-one network corresponds to one receiver layout. We believe the industry would benefit from adopting ASDF, since the format offers improved data organization, simple but efficient parallel processing, and provenance capabilities all wrapped up in a modern format.
Examples include storing time-dependent power spectral densities and combining them into probabilistic power spectral densities on the fly (e. g. McNamara & Buland 2004)  or building a database of historical earthquake data. Even non-seismological data, such as GPS time-series and magnetotelluric data, are not out of the question and would benefit from the provenance description and the advanced processing tools developed around ASDF. Some of these examples are already being attempted, and we intend to maintain a collection of use cases on our website.
C O N C L U S I O N S A N D F U T U R E D I R E C T I O N S ASDF has been developed with the broader seismological community in mind, and our hope is that scientists within this community will continually test, offer feedback, and improve the format and its associated tools. Through such a communal effort, we will gracefully meet future data challenges and empower ourselves to make new scientific discoveries. All components of the format, including its definition, implementation and other tools, are freely available under open source licenses and hosted on GitHub. A central entry point is the http://seismic-data. org website. We welcome any outside comments, criticisms and success stories, and we are committed to maintaining the documentation and implementations for the foreseeable future.
Figure1. The general structure of an ASDF file in its HDF5 container-it has four distinct parts: (1, yellow) Information about an arbitrary number of earthquakes (or other seismic events) is stored in a single QuakeML document, the most complete earthquake description format currently available. (2, green) Seismic waveforms are stored per station together with the necessary meta information in the form of an FDSN StationXML document. (3, red) Anything that cannot be regarded as a seismic waveform is hierarchically stored in the auxiliary data section. (4, blue) Provenance information is stored as a number of SEIS-PROV documents, an extension to W3C PROV. Background colours in the attributes (rectangular boxes) denote relations to other sections in an ASDF file. Examples of this are relations of a waveform to a certain event or a provenance record for a piece of auxiliary data.
A C K N O W L E D G E M E N T S This research was partially supported by the  EU-FP7   VERCE  project (number  283543 ) and  US NSF  grant  1112906. We are grateful for the  QUEST Initial Training Network (Marie Curie Actions , http://www. quest-itn. org) and the  Computational Infrastructure for Geodynamics (CIG , https://geodynamics. org/) organization for holding a joint workshop that sparked the creation of the ASDF format. This research used resources of the  Oak Ridge Leadership Computing Facility  at the  Oak Ridge National Laboratory , which is supported by the  Office of Science of the U. S. Department of Energy  under Contract No. DE-AC05-00OR22725. The authors also recognize support from the  NSERC G8 Research Councils Initiative on Multilateral Research Funding  and the Discovery Grant No.
BIM is defined by  Bentley (2016)  as "modelling of both graphical and non-graphical aspects of the entire building life cycle in a federated database management system". BIM is therefore called a rich model because all objects in it have properties and relationships and this information can be used for data mining to develop simulations or calculations using the model data  (Arayici, 2008). GIS "lets us visualize, question, analyse and interpret data to understand relationships, patterns and trends"  (ESRI, 2016). GIS modelling is rich in information because it is a computer-based tool to analyse and manage spatial, attribute, and relationship information among the elements. Both BIM and GIS represent opportunities for heritage digital modelling and conservation management. BIM is first used as a management of life-cycle construction process in architectural industry, which is suitable to parametrically model the historical building based on documentation data and record the temporal representation of heritage sites.
Anyway, to introduce BIM and GIS into the heritage modelling process, it still requires a methodological discussion and practical experimentation in order to obtain detailed models of irregular historical objects, especially from manual modelling to semi-automatic/automatic modelling. Now, the heritage modelling process is just in an early stage and some specificities are expected to be developed. This paper summarizes the current trend in historic modelling combining BIM and GIS, and then analyses some open and key issues related to the complexity, accurate geometric modelling and different level of details. The difficulty of historic building modelling compared to the classical modelling lies in its complex elements, which makes conventional approaches and software invalid. The accurately geometric modelling becomes difficult owing to the complex surface structures, which is necessary and essential to heritage conservation.
On the other hand, there exists some historic documentation about the heritage. According to the documentation data, the recreating process is just like the BIM process, by parametric modelling the elements and establishing the relations and then integrating the whole detailed building. In general, the commercial BIM tools can help to accomplish this process. ArchiCAD GDL language is used to build irregular and specific element library composing the historic objects  (Fai & Rafeiro, 2014). Although it is usually a manually time-consuming concept in BIM software to parametrically model the historic elements, the spatial relationship can be incorporated automatically in the modelling process. Once the enriched historic models are constructed, the models can be managed. GIS environment represents a common information system for the representation of 3D urban objects.
Typical work by  Murphy et al. (2013)  proposed the common procedure combining the documentation and laser scanning data, BIM platform and GIS environment. BIM software is firstly used to build the parametric elements about the built historic building based on documentation. The parametric objects are then mapped into the point cloud or image survey data to be refined and finally a reality-based accurate model can be obtained. After the creation of the 3D model, it may be integrated into 3D GIS for further analysis.
How to deal with the complex elements composing historic buildings? The first challenge comes to the complex elements composing the historic buildings, which makes historic architecture special compared to common and classical models and limits the application of commercial software aiming at regular geometry. In the one hand, the irregular and special elements do not exist in object libraries (IFC) and therefore cannot be directly included in usual BIM software. In the other hand, GIS are conceived to deal with simple 3D elements, and not for archaeological or historic models/sites, so that managing and analysing of complex 3D models can be generally problematic. So it can be profitable to use the capabilities of both BIM and GIS platforms to achieve the integration of a complex 3D building.
But the complexity of many elements and the lack of unified criterions makes it difficult to simultaneously minimize information losing and optimize geometric architectural conservation while the exchange process between the two kinds of information systems. It benefits to information consistency among the different BIM software, GIS software and other modelling software if the representation of the complexity of the irregular shapes of the elements tends to be simplified. Unfortunately, when the simplification has lost the details of architectural surface, it goes against the aim of heritage conservation and may result in an un-useful model. Till now, there exist three ways to parametrically model the irregular elements non-included in the BIM library: (i) The first one is the manually modelling of the elements in BIM software environment (Revit, ArchiCAD)  (Aubin, 2013).
The main drawback is its low efficiency and hard to assure the geometric accuracy. (ii) The second is the widely used programming Geometric Description Language (GDL) of ArchiCAD library parts  (Martens & Peter, 2002). The parametric GDL elements could be completely described as 2D symbols, 3D geometric models, attribute specifications and additional spatial relationships. (iii) The third is to build models with the help of 3D Graphics Software  (Barazzetti et al. 2015) , which could deal with any irregular shape object accurately compared to BIM platforms. As example, Rhino software is able to generate accurate models of complex and irregular geometries especially using NURBS for representing surfaces  (Oreni, 2014). BIM software could then add and manage the attribute and spatial relationship information.
, 2013). It means that the information loss mainly occurs in the irregular objects conversion from 3D graphic and BIM model to GIS environment. The BIM software are developing some plug-ins to help the conversion process or the integration of 3D graphics. And many works have been done to minimize the information loss in integrating of BIM and GIS. The common process is to extend the models from BIM to GIS, and a CityGML extension called GeoBIM to get semantic IFC data into GIS context is well developing  (De Laat and Van Berlo, 2011). BuildingSMART IFC is also extending itself for GIS project application, such as the new entity for spatial zones, geographic elements and external spaces  (Przybyla, 2010). Anyway a united system without information loss is not foreseen. In conclusion, critical aspects and barriers in the case of complex object modelling need to be further investigated to handle detailed models of irregular historical objects.
Using historical data to re-create the past has been a hot topic in 3D computer graphics, while the aim is mostly for visualization and to build a 2. 5D model. Typical work comes from the "Roma Reborn" project  (Dylla et al. , 2008) , which re-represent the ancient Roma based on historic photos and data records. Documentation-based approach is actually in accordance with the BIM concept, considering it generates a "new" historic building from the parametric elements to the whole entity possessing attribute and spatial relationship features. Moreover, the life-cycle characteristic makes BIM software suitable to the temporal and dynamic changing research about the historic objects. Fig. 2 : The processing of documentation-based Historic modelling approach (2) Reality-based approach Creating 3D models for historic objects based on 3D drawing is a time consuming process.
The knowledge library includes the digitalized historic manuscripts and architectural pattern books. It could also help the recognition and modelling process to address the point cloud. Parametric object library: Parameterization of the architectural elements is the essential characteristic of BIM. The parametric object could be obtained by commercial BIM software (simple and regular shapes) and corresponding plug-in (Dynamo in Revit), scripting language (GDL) or special graphic software (Rhino) for irregular elements. The parametric objects are dynamic in some extent and can instantly alter the shape, size and other properties by tuning parameters (Figure  6 ).
Therefore, image processing tools need to offer at the same time enough flexibility of use, a variety of algorithms, and efficient implementations to allow for fast iterations while adjusting the workflow. Several software applications and libraries are available to synchrotron users to process their images. ImageJ  [1, 48]  and its distribution Fiji  [45]  is a popular general-purpose tool for 2D and 3D images, thanks to its intuitive menus and graphical tools, and the wealth of plugins contributed by a vivid community  [46]. Software specialized in analyzing synchrotron data is available as well, such as XRDUA  [17]  for diffraction images obtained in powder diffraction analysis, or for 3D images, commercial tools such as Avizo 3D software (TM), or ToolIP/MAVIkit [19] are appreciated for an intuitive graphical pipeline and advanced 3D visualization.