dataesr/scientific-paragraphs-categorization huggingface dataset:
Choosing the Appropriate LUT as a Function of RH As introduced previously, a look-up table (LUT) is computed for each aerosol type, and also for a set of RH sampling values (defined in Section 2. 2. 3) for the aerosols which depend on RH. In order to use the right LUTs, the effective relative humidity has to be computed. To do so, the RH vertical profile is determined at the image centre by a linear interpolation using the RH data of the four closest neighbours in the CAMS regular grid. The effective RH at the image centre is then calculated as the average of the vertical profile, weighted by the AOT of each layer. The AOT of each layer (model level), used to weight the average RH, is computed as follows: • for each RH-dependent aerosol type (Sea Salt, Sulfate and hydrophilic Organic Matter), α e corresponding to the RH of the model level is interpolated.
Dataset Sentinel-2  [33]  is an Earth observation mission operated by the European Space Agency (ESA) and is part of the Copernicus program. This mission consists of the two satellites Sentinel-2A and Sentinel-2B which will soon offer high repetitivity data with a 5-day revisit period as well as a constant viewing angle and global coverage of land surfaces. Sentinel-2A was launched on 23 June 2015 and Sentinel-2B on 7 March 2017. They follow a Sun-synchronous orbit with a 786-km altitude and an overpass time at the descending node at 10:30 a. m. local time. Sentinel-2 provides data over 13 spectral bands, ranging from the visible spectrum to the near-infrared (NIR) and short-wave infrared (SWIR) spectra. The data used for this paper only come from the Sentinel-2A satellite which has a nominal repetitivity of 10 days.
Validation of AOT with AERONET In order to provide correct surface reflectances after atmospheric correction, the estimation of the aerosol optical thickness (AOT) must be accurate. To assess this accuracy we compared the AOT estimations at 550 nm from MAJA to the level 1. 5 observations from AERONET which have been cloud-screened  [45] , and to the level 2. 0 observations (cloud-screened and quality-assured with final post-calibration and manual inspection) when available. The Aerosol Robotic Network (AERONET) is a worldwide network of sites equipped with Cimel sunphotometers, providing aerosol data such as the AOT. The AOT uncertainty from AERONET with cloud-free conditions is <0. 01 for wavelengths >440 nm and <0. 02 for wavelengths <440 nm  [34]. A filter is applied to the AERONET data to match the Sentinel-2A overpass time and to define "stable cases".
2 (meaning enough vegetation); for the multi-temporal method, as we assume the surface reflectance varies slowly with time, the SWIR (which is more sensitive to surface reflectance changes than to AOT variation) surface reflectance must be close to the value of the previous date. Therefore, a pixel is defined as valid (i. e. , not gap-filled) if it verifies at least one of the two conditions. The AOT from MAJA is then compared to the mean AOT from AERONET data within 24 min around the satellite overpass time. This temporal window of 24 min is the result of an internal study, which has not been published. It was found to be a good balance between having enough AERONET data available and avoiding a too-large variation of the AOT. The following figures show the performances of the predicted AOT from CAMS (Figures  3a  and 4a ; after temporal interpolation as described in Section 2.
The imaginary part of its refractive index, which characterizes the absorption, is 0. 45. Such a value corresponds to a very high absorption that we found somewhat exaggerated, as compared to the values retrieved from AERONET data in  [16]. We tested the effects of choosing a lower absorption of 0. 20 for the Black Carbon. For the previous Figures  3d  and 4d  and for this study in general, this new Black Carbon refractive index of 1. 75 -0. 20i was used. Table  6  justifies this new refractive index by the observed reduction of errors compared to the Black Carbon refractive index used in CAMS (i. e. , 1. 75 -0. 45i). For this comparison, no temporal interpolation was applied, only the dates which are common to the two configurations are taken into account, and the performances are computed by comparing to the AERONET observations.
Conclusions The products from the Copernicus Atmosphere Monitoring Service (CAMS) were introduced in the atmospheric correction of Sentinel-2A time series by the MACCS-ATCOR Joint Algorithm (MAJA) software. Before this study, MAJA estimated aerosol optical thickness using a constant aerosol type. The study presented in this paper takes advantage of the aerosol optical thickness (AOT) forecasts from the CAMS system for five different aerosol types to select a variable aerosol type for the atmospheric correction. A weighted interpolation of these types is performed using the respective AOT predictions from CAMS to estimate the AOT present on the image. Several validation methods were used to assess the performances of this new configuration. Firstly, we compared the AOT estimated by MAJA to the ground-based observations from the Aerosol Robotic Network (AERONET).
Acknowledgments: The authors would like to thank  Mireille Huc  for her technical support and the staff establishing and maintaining the AERONET sites used in this paper. This study was first funded by the  CNES/TOSCA  ( Terre Océan Surfaces Continentales Atmosphère) program  and then by  CNES/THEIA  (Theia is the French public land data center). The authors would also like to thank the team supporting the  Plateforme d'Exploitation des Produits Sentinel (PEPS)  download platforms, and the  ECMWF  for managing CAMS as part of the delegation agreement with the  European Commission. We are grateful to the anonymous reviewers for their constructive comments, which helped to improve this manuscript.
INTRODUCTION C HANGES in hardware manufacturing technologies are driving systems to include ever more cores. Servers comprising hundreds of commodity hosts with tens of thousands of cores in total are becoming commonplace. Experience with high performance and data centre computing shows that reliability is critical at these scales, e. g. , host failures alone account for around one failure per hour on commodity servers with approximately 10 5 cores  [1]. Distributed actor languages and frameworks like Erlang  [2] ,  [3]  or Scala/Akka  [4]  are proven technologies for reliable scalable computing. The key innovation in actor languages and frameworks is to isolate state: that is, actors do not share state with each other but rather exchange information using asynchronous messages. In Erlang actors are called processes, and their isolated state means that they may fail with minimal disruption to concurrent processes.
Moreover one process may supervise other processes, detecting failures and taking remedial action, e. g. , restarting the failed process. Distributed Erlang deploys processes across multiple Erlang Virtual Machines (VMs or nodes) potentially on different hosts. In distributed Erlang fault tolerance is provided by global process registration, where the name of a server process is registered, and if the process fails a new server process can be spawned and re-associated with the name. This allows systems to adopt a "let it crash" philosophy, where a process is written to deal with the common error-free case, and failure is handled by the supervising process. While distributed Erlang conceptually supports the engineering of scalable reliable systems, in practice it has some scalability limits that force developers to depart from the standard language mechanisms when programming at scale  [5].
Reliability in Distributed Erlang Systems Erlang was designed to solve a particular set of problems, namely those in building telecommunications systems, where systems need to be scalable to accommodate hundreds of thousands of calls concurrently, in soft real-time. These systems need to be highly-available and reliable: i. e. , to be robust in the case of failure, which can come from software or hardware faults. Given the unavoidability of the latter, Erlang also adopts the "let it crash" philosophy in error situations, and uses the supervision mechanism, discussed shortly, to handle all kinds of faults. Scaling in Erlang is provided in two different ways. It is possible to scale within a single node by means of the multicore Erlang VM which exploits the concurrency provided by the multiple cores.
It is also possible to scale across multiple hosts using multiple distributed Erlang nodes. In this paper we only address the latter. Reliability in Erlang is multi-faceted. As in all actor languages each process has private state, preventing a failed or failing process from corrupting the state of other processes. Messages enable stateful interaction, and contain a deep copy of the value to be shared, with no references (e. g. , pointers) to the senders' internal state. Moreover, Erlang avoids type errors by enforcing strong typing, albeit dynamically  [2]. Connected nodes check liveness with heartbeats, and can be monitored from outside Erlang, e. g. , by an operating system process. However, the most important way to achieve reliability is supervision, which allows a process to monitor the status of a child process and react to any failure, for example by spawning a substitute process to replace a failed process.
BENCHMARKS AND A CASE STUDY To evaluate the performance of SD Erlang we use three benchmarks, named Orbit (Section 4. 1), Ant Colony Optimisation (ACO, Section 4. 2), and Instant Messenger (IM, Section 4. 3), and a case study (Sim-Diasca, Section 4. 4). The benchmark code is open source at https://github. com/ release-project/benchmarks. Each benchmark corresponds to a typical class of Erlang applications as follows. Orbit employs a Distributed Hash Table (DHT) of the type used in replicated form in No-SQL DBMS like Riak  [24] , implemented in Erlang. ACO is a large search, similar to the Erlang Sim-Diasca simulation framework  [25]. IM is a simplified version of a very typical internet-scale Erlang application, namely a chat service like WhatsApp [26].
We have implemented the following two versions. Reliable Distributed IM (RD-IM) is implemented in distributed Erlang where reliability is supported by supervision, global name registration of all processes that maintain databases, and replication of these databases. Therefore, when a database process fails it is restarted by a corresponding supervising process (Fig. 5 ). The table is then populated from a copy kept on a different node. In the meantime the data can be obtained from a replica. After the recovery process finishes the table can be accessed using the same globally registered name. Reliable Scalable Distributed IM (RSD-IM). Is implemented in SD Erlang with the same reliability mechanism as in RD-IM. The only difference is that in RSD-IM the names are registered in corresponding s_groups rather than globally.
Sim-Diasca Simulation of Discrete Systems of All Scales is a discrete simulation engine developed by EDF R&D in Erlang. Sim-Diasca has been available as free software since 2010 under the GNU LGPL licence  [25]. Its objectives are to evaluate correctly the models involved in a simulation, and preserve key properties like causality, total reproducibility and some kind of "ergodicity", i. e. , a fair exploration of the possible outcomes of the simulation. Using the requested simulation frequency, Sim-Diasca splits the simulated time into a series of time steps, automatically skipping those that can be omitted, and re-ordering the inter-model messages so that properties like reproducibility are met. Causality resolution requires time steps to be further divided into as many logical moments (called diascas) as needed.
In case of RSD-IM this results in three s_groups: one router s_group that consists of only two router nodes, and two server s_groups that consist of one router and six server nodes each. We first run experiments with no failures, then we terminate random processes, gradually reducing the rate from 15 and 5 seconds; finally we randomly terminate only globally registered database processes reducing the rate from 5 seconds to 1 second. The processes start failing five minutes into the benchmark execution once the applications are stable, i. e. , failures occur only between minutes 5 and 15. The throughput results in Fig. 12  show that the IM fault tolerance is robust and the introduced failure rate has no impact on either of the of the IM versions in the given scale (number of nodes).
TOOLS AND SYSTEM DEVELOPMENT How are scalable SD Erlang systems developed? This section outlines a general development strategy, from inception, though refactoring, performance tuning and operation. Here is not the place to rehearse the Erlang philosophy of concurrency-oriented programming, and the way that fault tolerance, robustness and distribution are integrated into the language and the OTP middleware layer: for more about this see  [40] ,  [41]. Instead, we look here at the twin issues of how to build systems in SD Erlang, and how to tune and operate those systems once built. Fig. 13  gives a schematic view of an SD Erlang system, and the tools that are used in building and tuning it. Each node is an Erlang runtime, running on a multicore host machine; these nodes are grouped into (overlapping, generally) s-groups, each of which forms a fully interconnected network.
From global_groups to s_groups SD Erlang extends distributed Erlang by extending Erlang's original communication mechanism and replacing the global_group library with a new s_group library. As a result, Erlang programs using global_group will have to be refactored to use s_group. This kind of API migration problem is common as software evolves. To support such changes we extended Wrangler to migrate client code from using an old API to using a new one, with group migration, explained above, as a special case. Our approach works this way: when an API function's interface is changed, the author of this API function implements an adaptor function, defining calls to the old API in terms of the new. From this definition we automatically generate the refactoring, that transforms the client code to use the new API.
Introducing a Generic Communication Pattern In the first SD-Orbit implementation, described in Section 5. 2. 1, there is strong coupling of s_group manipulation and the application logic, making it difficult to separate the specific (application) from the generic (groups and communications). Using a general refactoring tool to support operations such as function renaming, function extraction and moving functions between modules, it was possible to separate out the generic portion, a reusable s_group pattern. This reusable pattern provides (i) functions for setting up the s_group structure according to the pattern specified, (ii) functions for spawning gateway processes which are in charge of relaying messages from one s_group to another, and (iii) s_group-specific send and spawn functions.
While the runtime of the Sim-Diasca instance continues to fall up to 16 nodes, the available resources are not utilised efficiently: we get a reasonable speedup of 1. 5 on two nodes (32 cores), but it is only 2. 2 on four nodes (64 cores), and degrades to a maximum of 3. 45 on 16 nodes (256 cores). The Linux top command is used to investigate core and memory usage. The maximum core and memory usage are 69 and 14 percent (8. 96 GB out of 64 GB) respectively for a single 16-core node. The memory usage on a single host may become a bottleneck when running larger Sim-Diasca instances. As expected in a distributed system, both core and memory usage decrease as the number of nodes grow. Fig. 15  shows the network traffic, i. e. , the number of sent and received packets between nodes in the cluster during the case study execution.
Devo Devo is an online visualisation tool for SD Erlang programs. 1 There are two visualization options available to a user: "Low" and "High" level visualizations. The low level visualization shows process migrations and the run queue lengths of a single Erlang node, whereas the high level visualization shows nodes in s_groups using D3's force-directed graph functionality (Fig. 17 ). 2  The s_groups to which a node belongs are indicated by the colour(s) of the graph node representing the Erlang node, and the edges connect nodes within the same group. When a single node is in more than one group the node's colour is split between the appropriate colours. When the nodes 1. Devo is available online from github. com/RefactoringTools/devo 2. Neatly replicating the system architecture in Fig. 1.
CONCLUSION & FUTURE WORK Conclusion. In prior work we have investigated the scalability limits of distributed Erlang for engineering reliable systems, identifying network connectivity and the maintenance of global recovery information as the key bottlenecks. To address these issues we have developed a  Scalable Distributed Erlang library that partitions the network of Erlang nodes into scalable groups (s_groups) to minimise both network connectivity and global recovery data (Section 3). This paper presents a systematic evaluation of SD Erlang for improving the scaling of reliable applications using the Orbit, Ant Colony Optimisation, Instant Messenger) archetypal benchmarks and the Sim-Diasca case study outlined in Section 4. We report measurements on several platforms, but the primary platform is a cluster with up to 256 hosts and 6,144 cores.
We conclude that, even when global recovery data is not maintained, partitioning the fully-connected network into s_groups reduces network traffic and improves performance on systems with more than 40 hosts on the Athos cluster (Sections 5. 2 and 5. 3). RQ2: ACO has relatively simple reliability mechanisms, essentially a supervision tree with a single supervised process type. Reliability in IM is far more elaborate and realistic with multiple types of process supervised, and the potential for Chat_Session or Client databases to fail, and hence more elaborate recovery mechanisms. Chaos Monkey experiments with both ACO and IM show that both are reliable, and hence we conclude that SD Erlang preserves the distributed Erlang reliability model (Section 5. 4). RQ3: For reliable applications we show that SD Erlang scales better than distributed Erlang.
Comparing the weak scaling of the reliable GR-ACO with the unreliable ML-ACO shows that maintaining global recovery data, i. e. , a process name space, induces a huge amount of network traffic and dramatically limits scalability above 40 hosts. Comparing GR-ACO and SR-ACO weak scaling shows that scalability can be recovered by partitioning the nodes into appropriately-sized s_groups, and hence maintaining the recovery data only within a relatively small group of nodes (Section 5. 4. 2). We present a new systematic and tool-based approach for refactoring distributed Erlang applications into SD Erlang. The approach presents a set of design questions, and builds on a suite of new or improved tools for monitoring, debugging, deploying and refactoring SD Erlang applications (Section 6). We demonstrate the capability of the tools, for example showing that WombatOAM is capable of deploying and monitoring substantial (e.
g. , 10K Erlang VM) distributed Erlang and SD Erlang applications with negligible overheads (Section 6. 8). Future Work. The SD Erlang libraries would benefit from enhancements: e. g. , to automatically route messages between s_groups. It would be interesting to extend our preliminary evidence that suggests that some SD Erlang technologies and methodologies could improve the scalability of other actor languages. For example, the Akka framework for Scala could benefit from semi-explicit placement, and Cloud Haskell from partitioning the network  [47]. In the medium term we plan to integrate SD Erlang with other technologies to create a generic framework for building performant large scale servers.
This work was partially funded by the  CNRS  " Projet international de cooperation scientifique (PICS) " grant No  230310  (CoCoAlSeq). LvI was partially supported by  NWO , including  Vidi grant   639. 072. 602 , and partially by the  4TU Applied Mathematics Institute. MJ was supported by  Vidi  grant  639. 072. 602from   NWO. ML was supported by  Natural Sciences and Engineering Research Council (NSERC) ,  PDF  grant. FP is a member of the  VIROGENESIS  project, which receives funding from the  European Union 's  Horizon 2020 research and innovation programme  under grant agreement No. 634650. CS was supported by the  French Agence Nationale de la Recherche Investissements d 0 Avenir/ Bioinformatique  ( ANR-10-BINF-01-02 , Ancestrome). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
dMRI tractography techniques (Figure  1A-B  Standard neuroscience imaging software that relies on common reference atlas spaces is often not well suited for individual patient analysis due to the effects of brain tumors. To meet singlepatient clinical research needs, SlicerDMRI is built upon and deeply integrated with 3D Slicer, an NIH-supported open-source platform for medical image computing. 3D Slicer provides critical tools including automated and semi-automated image segmentation  [2]  to label tumor tissue, image registration to align images across timepoints or modalities  [3] , and data interchange with clinical informatics systems  [4]. 3D Slicer is downloaded over 75,000 times per year, with active users and contributing developers from around the world. SlicerDMRI builds on this foundation to provide a unique environment for end-to-end dMRI analysis in clinical oncology including imaging studies and intervention planning research.
org/citations. Computer Resource: SlicerDMRI Functionality SlicerDMRI includes clinician-accessible tools for end-to-end diffusion MRI analysis, including computation of tissue microstructure models (e. g. diffusion tensors), tracing of fiber tracts (tractography), and quantitative analysis of diffusion-derived measures. See Video 1 for a quick tutorial covering the installation and basic usage of SlicerDMRI. Technical computing expertise is not required to use the graphical user interface of SlicerDMRI. For studies in which multiple datasets will be processed in the same way (batch analysis), SlicerDMRI supports scripting of most computations.
github. com/SlicerDMRI. Interested developers may freely include or extend SlicerDMRI functionality in their own extensions for public distribution through Slicer or for private use. Information about Slicer extension development is available in the Slicer developer manual on slicer. org. We welcome potential code contributions to SlicerDMRI via the GitHub pull request system. Although end-users do not need any programming experience to install or use the software, interested developers and collaborators are welcome to request or submit features on the GitHub issue tracker at https://github. com/SlicerDMRI/SlicerDMRI/issues. Software issues may also be reported on the issue tracker.
DISCUSSION Surgery is the only proven treatment modality for CCA  (43) , and all formal evaluations of targeted therapies to date, performed in unselected CCA cohorts, have proved unsuccessful  (44). In this study, we analysed a cohort of nearly 500 CCAs from distinct geographical regions, including 94 CCAs covered by four genomic platforms. Integrative clustering of mutation, copy number, gene expression, and epigenetic data revealed four subtypes of CCA, each exhibiting distinct molecular and clinicopathologic features. Four lines of evidence highlight that clustering based on molecular profiles provides additional information beyond anatomical site. Firstly, anatomical site does not drive molecular subtypes, as evidenced by the reproducibility of the molecular subtypes within each anatomical site separately (Supplementary Fig.