dataesr/scientific-paragraphs-categorization huggingface dataset:
Software Architecture Several software and tools are required to prepare the different data formats, as well as to implement and calculate the monthly energy needs of the 3D building. They are mainly open source and freely available (Figure  2 ). LOD2 CityGML data on building was imported into the PostgreSQL/3DCityDB database with information about the geometry and the building coordinates. The 3DCityDB (http://www. 3dcitydb. org/3dcitydb) is a free open source package consisting of a database schema and a set of software tools to import, manage, analyze, visualize, and export virtual 3D city models according to the CityGML standard. This software includes a tool for importing CityGML data into a PostgreSQL database. Then, using a Python script, the surface and volume of each building was calculated within the Eclipse environment.
Eclipse is deployed to create a base workspace and an extensible plug-in system for customizing the environment. For this study, the PyDev plug-in (http://www. pydev. org) was used to work with Python scripts. Python supports connection to the PostgreSQL database (https://www. postgresql. org). Building typology datasets were collected in excel or CSV format. The climate data on monthly average temperature and wind speed were extracted from the Meteonorm 7. 1 software as CSV format. They were processed using Python scripts and stored as different tables in the PostgreSQL database (Figure  2 ). Other tools such as FZKViewer (https://www. iai. kit. edu/1302. php), QGIS, FME, pgAdmin III were also utilized to create the software architecture. ISPRS Int. J. Geo-Inf. 2018, 7, 447 6 of 22 extensible plug-in system for customizing the environment.
For this study, the PyDev plug-in (http://www. pydev. org) was used to work with Python scripts. Python supports connection to the PostgreSQL database (https://www. postgresql. org). Building typology datasets were collected in excel or CSV format. The climate data on monthly average temperature and wind speed were extracted from the Meteonorm 7. 1 software as CSV format. They were processed using Python scripts and stored as different tables in the PostgreSQL database (Figure  2 ). Other tools such as FZKViewer (https://www. iai. kit. edu/1302. php), QGIS, FME, pgAdmin III were also utilized to create the software architecture.
5. Calculation of the dynamic parameters: η ls utilization factor for heat losses (cooling mode), η gn utilization factor for heat gains (heating mode) 6. Reduction factor for intermittent cooling (a C,red ) and heating (a H,red ) 7. Calculation of cooling and heating need: For the cooling mode: Q C,nd = Q gn -η ls * Q ht (3) Q C,nd,interm = a C,red * Q C,nd (4) For the heating mode: Q H,nd = Q ht -η gn * Q gn (5) Q H,nd,interm = a H,red * Q H,nd (6) where, • Energy need for the intermittent heating mode in MJ All these calculation steps and equations were programmatically implemented in the Eclipse environment using Python scripts, PostgreSQL and other related tools (see Section 2. 3). Several scripts and functions were written in modular structure. They were divided into nine packages, which allowed inspection of intermediate results of the individual model components (Figure  3 ).
The intermediate results and final outputs of the monthly cooling and heating energy needs were also saved as tables in the PostgreSQL/3DCityDB database from which automatized graphs were prepared. The databases were connected with QGIS to visualize the results in 2D and were also exported to ArcScene for visualization in a 3D environment. Energy need for the intermittent heating mode in MJ All these calculation steps and equations were programmatically implemented in the Eclipse environment using Python scripts, PostgreSQL and other related tools (see Section 2. 3). Several scripts and functions were written in modular structure. They were divided into nine packages, which allowed inspection of intermediate results of the individual model components (Figure  3 ). The intermediate results and final outputs of the monthly cooling and heating energy needs were also saved as tables in the PostgreSQL/3DCityDB database from which automatized graphs were prepared.
Validation of Model A comprehensive three-step validation of the monthly model was performed to justify its applicability and robustness. At first, a review of the comparative validation results obtained by the different studies implementing the ISO 13790 method was performed. Second, to ensure the correct implementation of the method in Python programming interface, the input values and corresponding results suggested in the Annex J of ISO document  [8] , have been considered in the CityBEM. Finally, the energy needs of an office and a residential building were validated with a dynamic simulation model in TRNSYS.
Validation with Other Studies ISO developers have internally carried out error estimation and validation of the monthly methods. They concluded that the monthly calculation gives correct results on an annual basis, but the results for individual months close to the beginning and end of the heating and cooling season can have large relative errors  [8] , (Section 5. 3). Recently, several studies performed validation of ISO methods with widely used dynamic simulation software such as TRNSYS or EnergyPlus. Kristensen and Petersen  [13]  found out that the monthly quasi-steady-state model predicts a lower monthly energy need for space heating and higher monthly energy need for cooling compared to the dynamic model. Zangheri, Armani  [16]  found that the simplified monthly method tends to over-estimate the energy needs for cooling, especially for office buildings located in a Mediterranean climate.
The results obtained by Vollaro, Guattari  [11]  confirms that the monthly method tends to overestimate and underestimate of approximately 12% and 14% the cooling and heating energy demands respectively, compared to the results obtained from the dynamic simulation with TRNSYS. Kim, Yoon  [12]  carried out a deterministic and a stochastic comparison of simple hourly method with the EnergyPlus 6. 0 software, with the inputs and boundary conditions for both approaches as close to The CityBEM monthly model was applied in several European and Asian cities, with varying numbers of buildings in both LOD1 and LOD2 data. The multiprocessing package of Python was exploited to improve the computational efficiency of handling of large 3D city models. The model proves very efficient and quick in displaying results.
For example, in a typical virtual machine-a Linux Server for Python with 64 GB Ram, 12 GB used, 10 cores, HDD 8. 5 GB free and a PostgreSQL Server for the DBs with 16 GB Ram, 3. 5 GB used, 10 cores, HDD 44 GB free-it takes around 3 min to run on around 4300 LOD2 buildings, 8 min on 12000 LOD2 buildings, and 28 s on 600 LOD1 buildings.
The results obtained by Vollaro, Guattari  [11]  confirms that the monthly method tends to overestimate and underestimate of approximately 12% and 14% the cooling and heating energy demands respectively, compared to the results obtained from the dynamic simulation with TRNSYS. Kim, Yoon  [12]  carried out a deterministic and a stochastic comparison of simple hourly method with the EnergyPlus 6. 0 software, with the inputs and boundary conditions for both approaches as close to each other as possible. They found that in the deterministic method, ISO 13790 predicts less annual heating and cooling energy demands than EnergyPlus. In the stochastic approach, EnergyPlus showed higher stochastic robustness than ISO 13790. However, Vartieres, Berescu  [18]  found that the yearly cooling need obtained with the monthly method is almost three times higher than that of TRNSYS.
From May to October, the predicted cooling demands by ISO 13790 are smaller than EnergyPlus ones, while in the other months the predicted cooling demands are larger than EnergyPlus  [12]. Earlier Kokogiannakis, Strachan  [14]  confirmed that the monthly method demonstrates higher cooling needs than the other methods. The EU study in the ENTRANZE project concluded that heating needs in ISO monthly and hourly are in line with EnergyPlus but the cooling needs are different in some climatic conditions  [16]. Therefore, most of the studies found that the ISO method predicts less heating and more cooling needs, compared to the dynamic simulation software. CityBEM also shows similar patterns of cooling and heating needs.
Validation with TRNSYS The dynamic simulation software TRNSYS was used to validate the results of the cooling and heating energy needs obtained by the CityBEM. TRNSYS was used to simulate the behaviour of the transient system (http://www. trnsys. com) and the simulations were focused on assessing the performance of thermal and electrical energy systems. TRNSYS cannot perform simulations on multiple buildings at a time, so two individual buildings, e. g. , an office (built in 1975) and a residential building (built in 1985) in Karlsruhe were validated separately, with the same input data and assumptions as chosen in the CityBEM model.
Input Data Several inputs are required in TRNSYS. At first, the two buildings were extracted from the CityGML dataset to calculate the building geometries, e. g. , surface area of walls, roofs, etc. (Figure  7 ). yearly cooling need obtained with the monthly method is almost three times higher than that of TRNSYS. From May to October, the predicted cooling demands by ISO 13790 are smaller than EnergyPlus ones, while in the other months the predicted cooling demands are larger than EnergyPlus  [12]. Earlier Kokogiannakis, Strachan  [14]  confirmed that the monthly method demonstrates higher cooling needs than the other methods. The EU study in the ENTRANZE project concluded that heating needs in ISO monthly and hourly are in line with EnergyPlus but the cooling needs are different in some climatic conditions  [16].
Input Data Several inputs are required in TRNSYS. At first, the two buildings were extracted from the CityGML dataset to calculate the building geometries, e. g. , surface area of walls, roofs, etc. (Figure  7 ). Then, the building attributes and thermal characteristics (e. g. , surfaces areas, thickness and composition of walls, roof and ground layers, etc. ) were given as inputs in TRNSYS. Calculation of internal gains were different in both models, therefore, careful attention has been given to ensure the same input of heat gains in both models. For this reason, the internal gain was set considering the table from ISO 7730 as suggested in TRNSYS. Then, the scale was adjusted by considering the  Then, the building attributes and thermal characteristics (e. g. , surfaces areas, thickness and composition of walls, roof and ground layers, etc.
) were given as inputs in TRNSYS. Calculation of internal gains were different in both models, therefore, careful attention has been given to ensure the same input of heat gains in both models. For this reason, the internal gain was set considering the table from ISO 7730 as suggested in TRNSYS. Then, the scale was adjusted by considering the monthly aggregated values of the internal heat gains in order to ensure exactly the same inputs in both TRNSYS and CityBEM. Other parameters such as infiltration, ventilation, etc. were also considered identical in both models. The same Meteonorm weather data (wind speed, average temperature data) was given as an input. However, the TRNSYS software itself calculates the solar gains by the solar radiation model internally. An overview of the input datasets in TRNSYS software is given in Table  2.
Sensitivity Analyses Sensitivity analyses try to quantify how the different influencing factors related to geometric characteristics relevant to the 3D city models, and future climate scenarios, affect the monthly building heating and cooling energy needs at an urban scale. In this regard, at first, the applicability of such datasets were tested. Then, different sensitivity analysis approaches and associated assumptions were reviewed to identify a suitable method for the monthly building energy model. To process the large data sets, the calculation process was automated through Python scripts, 3DCityDB and PostgreSQL databases. Finally, the results were analyzed and visualized in different graphs and thematic 3D buildings. Two sets of sensitivity analyses, e. g. , parameter sensitivity and climate sensitivity were performed in this study.
Climate Sensitivity Sensitivity of future climate conditions were tested with the LOD2 CityGML data of the selected 95 buildings-having four building types (double-family house, multi-family house, apartment block, and high-rise apartment block) and three age categories  (1900-1948, 1949-1968, and 1969-1983) -in an urban district in Karlsruhe. In this regard, IPCC A2 climate scenarios for 2050 and 2100 were extracted from the Meteonorm 7 climate dataset. The Meteonorm software itself does not calculate any climate scenarios. The CityBEM was run on these datasets (assuming all other input parameters were constant; they were chosen according to Table  1 ) to compare the results with the reference climate scenario, which represents a typical meteorological year. The results show that the heating energy needs in all the buildings in this district in 2050 and 2100 will decrease, while the cooling energy needs will increase significantly.
Conclusions In this study, the CityBEM monthly model was developed through an open source implementation of the ISO 13790:2008 method to calculate monthly heating and cooling energy need for a large number of building stocks in a neighborhood or city. It was based on the 3D city models of the CityGML format and other required input parameters, such as the building geometry, typology and energy characteristics. The model was applied in several urban districts with varying numbers of buildings stocks, using both LOD1 and LOD2 datasets. The robustness of the model was also tested using a three-step validation approach. The model itself and the sensitivity analyses can help to determine the potential of energy efficiency in the buildings to reduce harmful environmental impacts. It can help urban decision makers to perform city or district wide analysis of the building energy need and to prepare different renovation plans, which finally will help to enhance the livability of the city and quality of life of the citizens.
Regarding handling of 3D data, we observed geometrical and topological errors in the CityGML dataset, which could not be completely imported into the PostgreSQL database, resulting in exclusion of some buildings in the analysis. Nouvel et al. [27]  and Agugiaro  [28]  also explained such uncertainties, e. g. , geometrical precision, thermal building parameters estimation, etc. , of the 3D city models. Finally, each building was modelled as single zone in this study. With the availability of more detailed building information, e. g. , LOD3 or LOD4 city models, buildings can be modelled as multi-zones. Such city models will also facilitate exact calculation of window or chimney areas and thus improve the modelling results. The ISO monthly method (and therefore the CityBEM model) can be further improved.
Acknowledgments: We are grateful to the city of  Karlsruhe  for providing the 3D city models as well as EDF R&D and EIFER for internal funding the research. We would like to thank  Hicham Bidah  and  Alexander Simons  for their initial support in application development. Finally, our sincere gratitude extends to the editors and three anonymous referees for their insightful comments, which helped us to improve the manuscript.
Previous Works In recent years, several software solutions have been introduced to facilitate DBS planning. Guo et al. introduced one of the first DBS planning platforms, which offered automated image registration, anatomical segmentation, and visualization for target localization  [5]. Miocinovic et al. created the Cicerone system for DBS electrode placement, which also allows users to visualize the volume of tissue activated  [6]. D'Haese et al. developed the CranialVault system for assistance through the pre-, intra-, and post-operative phases of the DBS workflow, including automatic prediction of the stimulation target point  [7]. D'Albis et al. proposed the PyDBS system for DBS planning and post-operative assessment, including atlas-based segmentation, automatic stereotactic frame registration, and automatic segmentation of electrodes from post-operative CT images  [8].
Software Implementation The training system for DBS planning was implemented in the 3D Slicer (www. slicer. org) environment (Error! Reference source not found. ) and may be installed on any Linux, Mac, or Windows computer. The DBS planning interface was based on the PyDBS software, which was used to register and segment the MRI images and allowed the patient cases to be readily loaded, visualized, and planned  [8]. The Perk Tutor platform (www. perktutor. org) was used to capture the planning process, calculate all measures of proficiency, and compute the feedback components  [23].
Study Protocol To validate whether the proposed training course has added value in the training process, we carried out a validation study. For this study, two expert neurosurgeons and six neurosurgery trainees were recruited at three centers in France and one center in Canada. Neurosurgeons who had planned at least 100 total DBS were considered experts; others were considered novices. Prior to beginning the training course, participants completed a questionnaire about their previous experience in DBS, were shown a brief demonstration on how to use the software, and allowed to familiarize themselves with the software. Subsequently, each participant followed the training course for DBS planning (expert participants skipped the two training phases). The ten patient cases were selected from real, anonymized patient data from patients with Parkinson's disease, representing a variety of anatomical variations.
Participants planned the trajectories at the inclusion phase of the workflow: patients had already been identified as good candidates for DBS, the target anatomy had been previously identified (STN or GPI), the T1-weighted and T2weighted MR images had already been taken, and the T2-weighted MR image along with an atlasbased segmentation had already been registered to the T1-weighted MR image using PyDBS. At the end of the training course, participants rated how difficult they thought each case was. Participants also completed a survey to assess the acceptance of the training software, based on the previously validated UTAUT  [24]. The survey included items concerning the usefulness of the provided feedback, the usefulness of the training course, and participants' interaction with the software.
Qualitative Evaluation of Training Software On average, novice participants agreed that training for DBS planning with the software was a good idea (6. 6 out of 7), the feedback provided by the system improved their understanding of the patient cases (6. 4 out of 7), and the software would be a useful part of a training curriculum   We installed the training software on a variety of different user-grade Linux, Mac, and Windows computers. In all cases, installation took less than thirty minutes, and performance was deemed acceptable based on informal operator feedback about responsiveness and image rendering quality.
g. checklist or global rating scale). To the best of our knowledge, no gold-standard exists for DBS planning. For this study, we validated the proposed measures of proficiency against DBS planning experience. Unfortunately, this does not account for instances where experts make mistakes or novices benefit from a stroke of fortune. We suggest this partially accounts for the overlap between the novice and expert groups with respect to the measures of proficiency. Because the training setup is exclusively software-based, it can be run on any modern computer. Thus, it could be readily installed in neurosurgery centers and allow trainees to independently practice and self-assess on a dedicated training station. Because the training setup is based on PyDBS, whenever PyDBS is used in practice to confirm DBS plans (as it is at the Centre Hospitalier Universitaire de Rennes), real patient cases can be readily transferred, in accordance with ethical bodies, to the training system.
Acknowledgements Matthew S. Holden  was supported by the  Natural Sciences and Engineering Research Council (NSERC)   Canada Graduate Scholarship. Travel was supported by the  Mitacs Globalink Research Award -Campus France  and the  Rennes Metropole Mobility Grant. Gabor Fichtinger  was supported as a  Cancer Care Ontario Research Chair in Cancer Imaging. This work was financially supported as a Collaborative Health Research Project (CHRP # 127797 ), a joint initiative between the  Natural Sciences and Engineering Research Council of Canada (NSERC)  and the  Canadian Institutes of Health Research (CIHR).
All service connections must be routed internally to the end-caps of the supermodule. Those that require materials with large radiation length are placed at the sidewalls, outside the active area of the TRD and most other detectors in ALICE. This includes the low-voltage power distribution bus bars as well as other copper wires for the Detector Control System (DCS) board power, network and high-voltage (HV) connections between the fanout boxes and read-out chambers, and the rectangular cooling pipes (see Section 4 for more details). Low-voltage (LV) power for the read-out boards is provided via copper power bus bars (2 for each layer and voltage as described in Table  3 ) with a cross-section of 6 mm × 6 mm (per channel) running along the sidewalls of the supermodule. Each read-out board is connected directly to the power bus bars.
7% for a supermodule with aluminium profiles and sheets and 30 read-out chambers (6 chambers per stack with the material budget as indicated in Table  2 ). The reduced material budget of the supermodules in front of the PHOS detector (carbon fibre inserts instead of aluminium sheets and no read-out chambers in stack 2) is likewise modelled in the simulation. In regions directly in front of PHOS X/X 0 is only 1. 9%. The total weight of a single fully equipped TRD supermodule as described in the AliRoot geometry, including all services, is 1595 kg, which is about 3. 3% less than its real weight. This discrepancy can be attributed to material of service components, such as the gas manifold (see Section 3. 3) and the patch panel, outside the active area, which were not introduced in the AliRoot geometry.
Slow control network The slow control of the TRD is based on Detector Control Systemboards  [70]. They communicate with the DCS (see Section 6) by a 10 Mbit/s Ethernet interface, mostly using Distributed Information Management (DIM) as protocol for information exchange. The use of Ethernet allows the use of standard network equipment, but a dedicated network restricted to the ALICE site is used. The DCS boards are used as end points for the DCS to interact with subsystems of the detector. Later sections will discuss how the DCS boards are used as interface to the various components, e. g. the front-end electronics or the GTU. The DCS boards were specifically designed for the control of the detector components and are used by several detectors in ALICE. At the core, the board hosts an Altera Excalibur EPXA1 (ARMv4 core + FPGA), which hosts a Linux operating system on the processor and user logic in the FPGA fabric depending on the specific usage of the board.