dataesr/scientific-paragraphs-categorization huggingface dataset:
JINST 14 P10017 The LHC 40 MHz input clock (fabric clock) is sent to a PLL to produce a TTC Clock at the same frequency, as well as 80 MHz and 200 MHz clocks for various other subsystems. TTC information is received through IDELAY and IDDR logic blocks and then processed in a hamming decoder block. The outputs of the TTC decoder block are the L1A and fast commands on an 8-bit bus. Pixel-related fast commands include ROC reset and TBM reset and other commands to e. g. reset event counters or clear buffers. Registers in the Pixel FEC register space count how many Pixel-related fast commands are decoded and a FIFO can capture all the TTC events. A trigger finite state machine (FSM) receives the fast commands and encodes the appropriate bit pattern into the TTC clock for transmission to the SFP as the module clock.
Phase-1 Pixel FED The Phase-1 Pixel FED consists of an FC7 board with a Rx-FMC. The Rx-FMC is a mezzanine containing two 12-channel optical receivers that collect signals from the sensor modules, and one SFP+ for data transmission to the CMS Central DAQ, as shown in figure  4  (left). One FED can read out 24 data streams of 400 Mb/s, and transmit output data at 10 Gb/s. The FED can also emulate and transmit data and run without a detector. The FED firmware consists of two parts. The first part (DECODE) handles decoding of the incoming data. The second part (BUILD) builds pixel events and sends them to the CMS Central DAQ. -13 -.
DECODE Pixel FED firmware The main task of the DECODE part of the Phase-1 pixel FED firmware is to decode the NRZI and 4b/5b encoded 400 Mb/s input signals, and to split the multiplexed TBM channels into two data streams. The decoding converts 24 multiplexed data streams of 400 Mb/s to 48 TBM core data streams of 160 Mb/s. A TBM core data stream starts with a TBM Header, followed by an 8-bit event number. This is followed by ROC Headers which indicate the beginning of pixel data. A TBM Trailer followed by 16-bits of status information terminates the data stream. The DECODE part of the Phase-1 pixel FED firmware (figure  9 ) was designed to automatically find the best sampling point for the incoming 400 Mb/s signal and to do continuous sampling phase finding without disturbing data integrity.
The optical receiver output, which carries the 400 Mb/s data stream, drives a differential input buffer of the FPGA. The negative output of this buffer is used as a copy of the incoming data stream to perform sampling phase finding and phase correction calculations. The DECODE firmware detects TBM Header, TBM Trailer, and ROC Headers and writes pixel data in so-called TBM FIFOs. Several checks are included to keep data integrity as high as possible. Therefore, not only does the TBM Header marker have to be identified to start a data packet, but also the beginning of the next marker (ROC Header marker or TBM Trailer marker depending on the data packet) is included to validate the start sequence. ROC Headers are only allowed within the expected delay after the arrival of a TBM Header. The number of ROCs is counted and an error is reported if the count does not match the expected number from the TBM type.
Furthermore, veto conditions for Header and Trailer arrival times and controllers that check the sequence of Headers, Trailer, and pixel data are added to avoid corrupted data packets. At this stage the TBM 4-bit words, which are the outcome of NRZI decoding, are combined with a 4-bit qualifier marker. This allows the following stage to identify these words as Header, Trailer or pixel information. In order to keep the event throughput per unit time roughly constant the DECODE firmware truncates the data volume by terminating the TBM core data stream when the TBM FIFOs get filled to a programmable value or too long payloads are sent from layer 1 modules. The data stream from the DECODE firmware block to the BUILD firmware block contains an overflow error type in this case. The bitwise signal of the events might be altered which causes errors in the FED.
The FED has multiple error counters, which can count independently for each channel. The data streams are forwarded to the BUILD firmware block using a 36-bit wide interface with the possibility of clocking data out at 40, 80, or 160 MHz. The default frequency for clocking out data is 160 MHz. For debugging purposes, the DECODE part of the firmware has fiber-specific spy FIFOs which store the incoming 5-bit symbols and the decoded 4-bit data words. To monitor the data transfer to the BUILD firmware part, additional spy FIFOs for every TBM channel are implemented.
BUILD Pixel FED firmware The BUILD FED firmware was designed to handle the data readout of 48 data streams coming from the DECODE FED firmware, transmit data to the CMS Central DAQ via the S-Link Express interface, and communicate with the TCDS system for the TTC and TTS interfaces for synchro--14 -  nization. The major challenges are the high data rate, the asynchronous readout with large payload variations between streams and from event to event, maintaining the synchronization, as well as the exception and error handling. Exceptions can occur due to corrupted data provoked by an SEU or sensor modules not sending coherent data. The 1-Gb/s Ethernet/IPBus communication is used to read out information about these exceptions during physics data taking. The block diagram of the BUILD FED firmware is shown in figure  10.
The READOUT firmware block encodes the data coming from the DECODE block, merges all the data fragments, detects and marks exceptions and transmits the merged data to the CMS Central DAQ. The firmware block uses separate FIFOs for L1As and pixel data and, in order to increase the data throughput, it drains the pixel data FIFOs in parallel. The parallel data draining structure allowed to exploit almost the complete potential bandwidth of the used hardware, as discussed in section 7. 2, and ensured safe running for the conditions expected during LHC Run 2 and Run 3. The READOUT firmware block also computes and transmits its own individual TTS state which is computed based on the filling level of the L1A and pixel data FIFOs, synchronization loss detection and received TTC commands. The TTS states used in the READOUT firmware block in the BUILD firmware are ready (RDY), busy (BSY), and out-of-sync (OOS).
Pixel FED data payload The sensor modules transfer zero-suppressed data to the Pixel Detector DAQ system via 2368 optical fibers. The average number of hits in a sensor module decreases with its radial distance from the interaction point. Figure  12  (left) shows the average number of pixel hits per event for all channels. The distribution is uniform for the outer layers in BPIX and in FPIX, while the average number of received hits per event has a large spread for the innermost layer. The twelve channels of each receiver have been chosen from sensor modules of different layers and at different z-coordinates in order to balance the data processing load on the FEDs. Most FEDs take two of these fiber bundles as inputs. Figure  12  (right) shows the distribution of average hits per fiber bundle (ribbon) and per FED.
The data load is distributed equally across the fiber bundles and thus also across the FEDs, with the FPIX FEDs (FED number > 96) receiving somewhat higher data rates on average than the BPIX FEDs (FED number ≤ 96). At a pileup of 46, for BPIX the average data payload is 10 hits per event per fiber, and thus lowest, for fibers connected to layer 4 modules. Layer 2 and 3 modules have an average data payload of 15-20 hits per event per fiber. Data payload for layer 1 modules fluctuates between 20 and 40 hits per event per fiber. For FPIX the data payload is 16-18 hits per event per fiber for outer ring modules and 35-40 hits per event per fiber for inner ring modules. The average throughput for a BPIX FED at a pileup of 46 at 100 kHz of triggers is approximately 1. 7 Gb/s. As discussed in section 7.
System tests in the CMS Detector -Phase-1 Pixel Detector Pilot System In order to be well prepared for a short commissioning period during the extended year-end technical stop at the beginning of 2017 and to take advantage of the lengthy access to the original detector possible during LS1, a pilot system  [34]  was built with eight prototype Phase-1 sensor modules. -17 - The pilot system was installed in 2014 in the available space in the original FPIX half cylinders (figure  13 ). A prototype microTCA FED system was used to read out the pilot system. The motivation for installing the pilot system was to learn how the readout, control, and offline systems perform in the CMS environment and to start integration with the CMS DAQ. The pilot system was commissioned before installation at CERN using a test stand running a standalone test software.
Calibration procedures for the pilot detector implemented in the online software were validated after the installation in CMS. During the pilot system tests before installation it was observed that the prototype FED was not able to correctly decode the data at high trigger rates. The issue was traced back to two separate sources: an asymmetric eye diagram due to the TBM design, and jitter on the Phase-1 portcard. While an asymmetric eye diagram could be accepted for the pilot system, new versions of the TBM were designed for the final Phase-1 sensor modules that were built in 2015 and 2016. In order to address the jitter on the portcard, an external QPLL chip had to be added in between the TPLL and Delay25 chips on the pilot portcard. Figure  14  shows asymmetric eye diagrams for one of the pilot modules before and after QPLL installation.
For the final Phase-1 portcards, the design incorporated the QPLL chip directly on the PCB. After the installation in CMS, the pilot system was used to validate the FED firmware. Both the DECODE and BUILD firmware blocks were iteratively improved during pilot system operations within CMS and the DECODE firmware block was finalized. Six out of eight pilot sensor modules were successfully used for data taking. Clusters are formed from signals from individual pixels by the reconstruction software and the hit position is determined by their barycenter. Figure  15  (left) shows the measured cluster positions projected onto the transverse plane. Figure  15  (right) shows the expected hits, which are derived from extrapolated tracks that are reconstructed in the FPIX detector (without pilot detector hits).
JINST 14 P10017 in the CMS service cavern. A rack layout identical to the final setup in the cavern containing all of the production parts, power modules, AC-DC converters, crates, service boards, as well as FEDs and FECs was operated for several weeks before installation. The soak test included regular firmware upload, and power cycling of FEDs and FECs. To facilitate the development and the validation of the pixel FED firmware a dedicated tool (FED tester) and a setup for high data rate tests were developed. These are described in the next two sections.
FED tester setup The FED tester, a data emulator, was designed for the Phase-1 pixel detector upgrade based on the gigabit link interface boards (GLIBs)  [38]  combined with the same FMC as used on the FECs to transmit the emulated data. FED tester customization enables consistent tests of the FED firmware from version to version. Custom firmware and software was developed to emulate the data bit stream from sensor modules with different TBM and ROC types. Once it receives a trigger emulated data streams are generated and sent: a TBM Header, ROC Headers, pixel hit data, a TBM Trailer, and 16 bits of status information in every data stream. The software is able to generate data patterns in the FED tester framework and can validate the output from the FED the data are sent to. The GLIB firmware is able to independently emulate 16 TBM core data streams.
Three GLIB boards are used to completely fill one FED, and optical splitters can be added in order to feed multiple FEDs in parallel. Each group of two TBM core data streams is then multiplexed, and NRZI and 4b/5b encoded before being transmitted. The content of the FED error counters are readout in the FED tester framework to confirm that the count for each error is accurate. Event generation can be done with a fixed data size, where every event is the same, or in SRAM mode, where the event size and pixel location can be programmed via software. The SRAM of the GLIBs is a software loadable memory that can be accessed by the event readout framework. There are two separate memory locations that each hold approximately 8. 4 MB of data. The first SRAM is designated to hold the distributions of hits per ROC.
It was also used to optimize the AMC13 configuration for the pixel use-case, and to study the propagation of the TTC commands from TCDS via the AMC13 to the FEDs. It continues to be used as a test bench to test new FED firmware releases, before their deployment in the production system. It is possible to check the data sizes through the S-Link Express link of the FED using the high rate test setup. When the event sizes are too large the trigger throttling limits the maximum data throughput. The throughput is tested by using fixed-size data and SRAM data, to allow for more realistic conditions. The maximum pileup during LHC Run 2 was approximately 60 (less than 16 hits/TBM core data stream for an average BPIX FED). 2 For up to 48 hits/TBM core data stream the FED can run at 100 kHz. Throttling of triggers starts at 56 hits/TBM core data stream and data throughput reaches approximately 7.
Hardware access and supervisors For each type of back-end electronics board in the pixel system a corresponding controller class exists. The controller provides the software interface to the hardware and allows access to the hardware functionality within the POS. It uses the CACTUS framework  [40] , which provides a hardware abstraction layer (HAL) for microTCA hardware. For the actual communication with the hardware the IPBus protocol is used. This protocol is transported via IP and Ethernet. The hierarchical structure of the POS is shown in figure  17. In order to prevent conflicts due to potential concurrent hardware accesses, the connection is established via a so-called control hub, which is a service daemon running on a separate computer (machine) that queues incoming requests from different applications and distributes them to the actual hardware.
Operation performance The CMS Phase-1 pixel detector has collected data in 2017 and 2018 with 95. 5% and 94. 4% functional channels, respectively. The non-functional fraction was due to infrastructure issues, caused for example by connector failures, and damaged sensor modules. Software recovery mechanisms and periodic ROC resets are implemented to reduce dead-time, ensure smooth running and maintain a high level of hit efficiency for BPIX layer 1. -23 -.
In order to have a full overview of the system the information is then sent from the FEDSupervisor to the PixelSupervisor. In the PixelSupervisor a new thread is started periodically requesting the SEU status count from all FEDSupervisors. When a programmable threshold is reached, which can differ between different parts of the detector for their impact on the data quality, a request to stop the triggers is sent to the CMS Central Run Control System. When the triggers are paused the Pixel FECs are notified to reprogram all the TBM settings. When the TBM is in a controlled state the ROC settings are reprogrammed. In order to use the time of the paused triggers effectively almost all settings are reprogrammed for the whole detector. Only the trim and mask settings are programmed specifically for the sensor modules affected by the SEU.
The PixelSupervisor waits until the Pixel FECs have finished this operation and then signals to the CMS Central Run Control System to restart triggers. This procedure takes approximately five seconds. One problem of the current version of the TBMs is that some SEUs result in a state where the TBM no longer processes triggers. The mechanism for this is understood and has been solved in the revised version of the TBM that will be used for the replacement of the innermost BPIX layer during LS2. For the TBMs currently used in the detector the only solution to revive the TBMs is a power-on reset of the TBM, which means that the low voltage supply of the TBM needs to be switched off and on again. Because of the design of the pixel detector this can be done by disabling the corresponding DC-DC converter; alternatively if a complete low voltage channel is disabled between 14 to 22 sensor modules are turned off.
This is followed by the programming of all the affected sensor modules using Pixel FECs. If after this recovery the channels still do not send data to the FEDs, the corresponding channels are masked in the FEDs. -24 -Figure  18  shows the number of ROCs that do not send data as a function of time in BPIX layer 1 during data taking for an LHC fill in 2017. More ROCs become inactive over time due to SEUs in the TBM (0. 7%/100 fb -1 ). After a programmable threshold is reached the SEU recovery mechanism is activated as described above, during which triggers are paused. Once the triggers are resumed the number of inactive ROCs is again at the baseline value (roughly 1% of BPIX layer 1 ROCs are not functional). The SEU rate depends on the instantaneous luminosity, which decreases over the time of the fill.
Conclusion The CMS Phase-1 pixel detector DAQ system was developed based on a combination of custom and standard microTCA parts to satisfy the higher bandwidth requirement of the new pixel detector and to interface correctly to the upgraded front-end electronics and optical links. The DAQ system underwent a series of integration tests, including readout of the pilot pixel detector, quality assurance of the Phase-1 detector during its assembly, and testing with the CMS Central DAQ. It was tested with realistic data streams at high trigger rates (up to 100 kHz) expected during LHC running. The Phase-1 pilot detector system proved to be valuable, leading to new designs for the TBM and the portcard to address an asymmetric eye diagram and excessive clock jitter, and helping with FED firmware development.
Acknowledgments The tracker groups gratefully acknowledge financial support from the following funding agencies:  BMWFW  and  FWF (Austria) ;  FNRS  and  FWO (Belgium) ;  CERN ;  MSE  and  CSF (Croatia) ;  Academy of Finland ,  MEC , and  HIP (Finland) ;  CEA  and  CNRS/IN2P3  (France);  BMBF ,  DFG , and  HGF (Germany) ;  GSRT (Greece) ;  OTKA K124850 ,  NIH , and  Bolyai Fellowship of the Hungarian Academy of Sciences (Hungary) ;  DAE  and  DST (India) ;  IPM (Iran) ;  INFN (Italy) ;  PAEC (Pakistan) ;  SEIDI, CPAN, PCTI  and  FEDER (Spain) ;  Swiss Funding Agencies (Switzerland) ;  MST (Taipei) ;  STFC  ( United Kingdom );  DOE  and  NSF  (U. S. A. ). Individuals have received support from  HFRI (Greece).
Correction Following the project's objective, this dataset can be used to analyse the conceptual relationships between verbal anchors of one scale, or between one or more scales. For example, thermal sensation is most frequently assessed using the seven-point ASHRAE thermal sensation scale, with the verbal anchors "cold", "cool", "slightly cool", "neutral", "slightly warm", "warm", and "hot". A common assumption related to the application of the thermal sensation scale is the assumption of equidistance, meaning the difference between "warm" and "hot" is equal to that between "warm" and "slightly warm". However, research has questioned this assumption  9, [11] [12] [13] [14]. Hence, the applicability of statistical methods relying on them (e. g. linear regression) needs to be questioned. Beyond reviewing the validity of this assumption, the newly developed questionnaire also enables to analyze the influence of different contexts (e.
g. language, climate, and season) and characteristics of individuals (e. g. sex). Further assumptions existing for other dimensions of thermal perception, here: thermal comfort and thermal acceptance, can be assessed also. Another important assumption in the field of thermal comfort to be reviewed through our dataset, postulates that occupants would be satisfied with the indoor thermal conditions, if they chose one of the middle three verbal anchors of the ASHRAE thermal sensation scale ("slightly cool", "neutral", or "slightly warm"). In other words, 'neutrality' is assumed to be a desired condition. Various studies have shown individual and contextual differences not supporting this assumption  9, 12, 13, [15] [16] [17]. In particular, researchers repeatedly identify a discrepancy in users who declare satisfaction while feeling warm or cool  [18] [19] [20] [21].
the Scales Project, a cross-national dataset on the interpretation of thermal perception scales Marcel Schweiker et al. #  thermal discomfort is one of the main triggers for occupants' interactions with components of the built environment such as adjustments of thermostats and/or opening windows and strongly related to the energy use in buildings. Understanding causes for thermal (dis-) comfort is crucial for design and operation of any type of building. the assessment of human thermal perception through rating scales, for example in post-occupancy studies, has been applied for several decades; however, long-existing assumptions related to these rating scales had been questioned by several researchers. the aim of this study was to gain deeper knowledge on contextual influences on the interpretation of thermal perception scales and their verbal anchors by survey participants.
The dataset consists of data from a large-scale international survey applying a newly developed questionnaire, which asks survey participants to state their perceived distance between the verbal anchors. The questionnaire was applied in 21 language versions. Surveys were conducted in 57 cities in 30 countries resulting in a dataset encompassing responses from 8225 participants (Fig. 1 ). Because individual inputs are available for each dimension of thermal perception, potential analyses and their statistical power benefit from the within-subject nature of this questionnaire.
The initial core group also developed the questionnaire in an English version. Mandarin (with simplified Chinese), German, Korean and Swedish translations were subsequently prepared by native language experts familiar with the concepts used in the questionnaire. Each group piloted the initial version of the questionnaire according to the following procedure: The questionnaire was applied without further explanation to at least 7 individuals, of which 2 had to be experienced in the field of human thermal comfort. After collecting the questionnaires, researchers discussed with the participants the length of the questionnaire, the clarity of instructions, and issues when filling out the questionnaire. The observations made through these applications were discussed among the core group and reflected in the revised and final versions of the questionnaire.
expansion of research group. After agreeing on a final version of the questionnaire and submitting the PAP, the initial core group reached out to other researchers in the field through existing networks, such as the Network for Comfort and Energy Use in Buildings (NCEUB) (http://nceub. org. uk/), and personal contacts. Additional researchers had to sign a co-author agreement and guarantee to follow the procedures prescribed for data collection (see below). In case researchers used other languages than the above mentioned, they had to translate the questionnaire into their language following the same procedure as initially applied -including piloting the new language version with at least 7 individuals beforehand. The number of 7 individuals was based on observations by the initial core group during the first pilot phase revealing that the number of issues raised by test participants concerning the questionnaire do not increase substantially with a higher number of initial respondents.