dataesr/scientific-paragraphs-categorization huggingface dataset:
3 , where the width of the white border between the shaded region and the delimiting Ewald spheres corresponds to the radius of a reflection. If the center of a reflection is within the shaded area it will be fully measured. Of course, not only do reflection widths vary from sample to sample, they can also vary with hkl and they may be asymmetric, so the simple picture given in Fig. 3  may need to be modified for real data. Note that reflections close to the origin of the reciprocal lattice will never be fully measured in a single shot. On the other hand, an increasing number of reflections are fully measured as the diffraction angle increases. Datasets with increasingly larger borders were constructed. The internal R value (R int ) and completeness provided by the cctbx software  (Grosse-Kunstleve et al.
, 2002)  were used to monitor the datasets up to a resolution of 1. 0 A ˚(Fig. 4 ). For all samples, a clear decrease in R int is observed. An R int of ~10% Ewald construction showing the 4%-energy-bandpass experiment (proportions exaggerated to show more detail). The reciprocal lattice points are shown as large dots to indicate that the intensities associated with them have a finite width. For simplicity, the reflections here are assumed to be isotropic and the widths identical for all reflections. The white borders between the Ewald spheres delimited by 1/ min and 1/ max and the shaded area correspond to half the reflection width (see main text). Here, four reflections are fully measured (red) and three partially (blue). (or less) is achieved for all three samples with a border of 2Â10 À3 A ˚À1.
This level is directly related to the elimination of partially measured reflections near the two boundaries of the energy range and close to the origin of the reciprocal lattice. The corresponding completeness values are still more than 80% for these reduced datasets (Fig. 4b ). On the other hand, the resolution range gets smaller, because the lower resolution reflections are only partially measured and are therefore removed. As a result, the lower resolution limits for sanidine, Cs 2 [Pt(CN) 4 ]ÁH 2 O, and ZSM-5 decrease from 6. 648 to 2. 234 A ˚, 7. 777 to 2. 344 A ˚, and 11. 126 to 2. 653 A ˚, respectively. Full datasets (partially measured reflections included) and reduced datasets were used for structure solution using the charge-flipping algorithm  (Oszlanyi & Su ¨to , 2004)  in Superflip  (Palatinus & Chapuis, 2007).
The structures of the three samples could be solved in all cases, despite the presence of partially measured reflections in the full datasets. The electron density map obtained with the ZSM-5 data is shown in Fig. 5  to give a visual impression of the quality of the data. After structure solution, an agreement value R ¼ P jI cor À sF 2 calc j P I cor ; where I cor is the corrected integrated intensity, s is the scale factor and F 2 calc is calculated from the structural model (obtained in the structure solution step), was calculated for each frame, in order to identify any outlying frames (i. e. frames with one or more partially measured reflections). Individual agreement values calculated for the full dataset and for a reduced dataset are shown graphically for all three samples in Fig. 6.
For each sample, the optimal reduced dataset was chosen as a compromise between completeness (! 80%) and quality (R int 10%). With the full datasets, the agreement values are highly dispersed (R up to 50%), and many outliers   (R > 50%) are present. However, with the reduced datasets, most of the agreement values lie below 25%, and only a few outliers (R > 30%) can be seen. This is consistent with the presence of partially measured reflections at the borders of the energy range and close to the origin of the reciprocal lattice in the full datasets. For ZSM-5, the six frames in which a and b were wrongly assigned in the indexing process are the most obvious outliers. The other two with agreement values slightly above 30% result from the presence of a single partially measured reflection still remaining in each frame.
For Cs 2 [Pt(CN) 4 ]ÁH 2 O, no outliers can be spotted in the reduced dataset. For sanidine, the number of outliers in the reduced dataset is larger than for the other two samples. This is related to the presence of one or two partially measured reflections in these particular frames. The reason for the partial measurement of these reflections is mainly related to the intrinsic breadths of the sanidine reflections. From the conventional monochromatic datasets, the average widths of the Bragg reflections were extracted for each of the three test samples using the CrysAlis software (Oxford Diffraction, 2008) (Table  3 ). The widths of the sanidine reflections are clearly larger than those of ZSM-5 and Cs 2 [Pt(CN) 4 ]ÁH 2 O, so for sanidine the border at the boundaries needs to be increased even further, if only fully measured reflections are to be included.
This can also be seen in Fig. 4 , where the R int value reaches a plateau when all reflections on all frames within a dataset are fully measured. This happens at a much larger border size for sanidine than for the other two samples. Structure refinements were then performed with the SHELX software  (Sheldrick, 2008)  using the reduced datasets (2Â10 À3 A ˚À1 border for ZSM-5, and 2. 5Â10 À3 A ˚À1 for sanidine and Cs 2 [Pt(CN) 4 ]ÁH 2 O). Frames with an R value above 0. 3 for ZSM-5 and sanidine were discarded. Atomic coordinates, displacement parameters, and an overall scale factor were allowed to vary. In all three structures, anisotropic displacement parameters were used for the cations and isotropic ones for the oxygen atoms. Refinement results are given in Table  4. Agreement values obtained from a conventional monochromatic refinement are also given for comparison.
Conclusion The fact that single snapshot diffraction patterns from materials with small unit cells can indeed be indexed opens up new horizons for the structure analysis of polycrystalline materials. It means that high-quality single-crystal X-ray diffraction data can be obtained from tiny crystals in a very short period of time, and this has implications for all areas of materials research, particularly for beam-sensitive samples. Furthermore, because several crystals can be measured simultaneously, agglomerates do not pose a problem and a useful subset of a full dataset can be measured with a single 10-50 femtosecond pulse. The latter offers exciting possibilities in the area of time-resolved experiments. The unique 4%energy-bandpass mode that is planned for the SwissFEL  facility is particularly well suited for this kind of experiment, because it allows more reflections to be measured in a single shot, and they are measured completely.
Acknowledgements We thank the  SNX Council of SNBL  for granting us beamtime to perform the experiment. Funding from the  Swiss National Science Foundation and Chevron ETC  is gratefully acknowledged. The Advanced Light Source is supported by the Director,  Office of Science, Office of Basic Energy Sciences, Materials Sciences Division , of the  US Department of Energy  under Contract No. DE-AC02-05CH11231  at  Lawrence Berkeley National Laboratory and University of California, Berkeley, California.
Towards simulation-based and augmented learning for complex physics Based on the two-stage strategy presented before, one offline intensive computing phase followed by a fast real-time on-line simulation phase, the authors have developed and implemented a PGD platform able to run on smartphones and tablets running Android or iOS operative systems, but also standard epub or html formats. In our implementation, the different F j i are usually stored as one-dimensional arrays of values, thus minimizing the needed memory usage. Note that the Android 3. 0 operative system, for instance, precludes the use of more than 65,536 points (nodes) in the model. This is avoided using meshes of the boundary of three-dimensional solids only, instead of a fully 3D-mesh. In Fig. 1 , a screenshot is shown on the appearance of the application developed using html and javascript.
This was one of the first projects to make use of virtualisation, enabling the software to run on many platforms without recompilation. In early 2014 a volunteer computing project was started within the ATLAS experiment  [4]  for two purposes: to provide extra opportunistic resources and to involve the general public directly in ATLAS data processing. The latter reason is a very important part of volunteer computing, allowing people have a direct connection with scientific research. The rest of this paper describes the ATLAS@Home project in detail. In Section 2 the architecture and implementation of the project is described, then in Section 3 the experience and results so far are shown, and finally in Section 4 some conclusions are drawn.
For each work unit the BOINC client boots a Virtual Machine (VM) which runs the required operating system and the work unit is processed inside the VM. In addition to easing the life of application developers this provides an extra layer of security by containing applications in an environment isolated from the volunteers' main operating system. When deciding the type of work units to run in ATLAS@Home there were several considerations to take into account. Firstly the unreliable nature of the resources means that only low-urgency tasks can be run. In contrast to regular Grid sites running ATLAS tasks the volunteers may be located far from the data on a poor Internet connection which means that tasks processing large amounts of data are also not suitable. The type of tasks which fit best these requirements are low priority Monte Carlo Simulation tasks.
These tasks involve generating random collisions inside a simulated ATLAS detector, and modelling their trajectory and interactions with the various detector components. This is a vital part of the overall process of analysing data from ATLAS as it provides both detailed information on the detector itself and a means of comparing the observed data against theoretical models. On a technical level there were further issues to consider in the design of ATLAS@Home. The software used for Monte Carlo simulation is extremely complex and only runs on specific operating systems seldom used by the general public and so virtualisation is the only way to attract significant numbers of volunteers. The CernVM project  [6]  provides virtual images tailored for the LHC experiments' software and these images can run seamlessly inside the virtualisation layer provided by BOINC.
ATLAS software is provided to the VM through the CernVM File System (CVMFS)  [7] , a remote read-only filesystem using aggressive local caching which is mounted inside the image. To avoid downloading the software every time the VM is started, the CVMFS cache inside the image is pre-filled with the required software, by running an example job, saving a snapshot of the image, and using that snapshot as the final image to distribute to volunteers. One critical requirement was that no ATLAS credentials should be distributed to volunteers. In regular Grid jobs a proxy certificate is passed through to the worker node on which the job runs, so that the job can communicate with the central workload management system and stage data to and from Grid storage. Having this certificate accessible to volunteers would provide access to and even the ability to delete ATLAS data on the Grid which is obviously unacceptable.
The solution was to use the model deployed in NorduGrid [8] and other environments such as High Performance Computing centres which have restricted access to the outside world from the job worker nodes. In this model the ARC Computing Element (ARC CE)  [9]  takes care of data staging before and after the job runs and the ARC Control Tower  [10]  provides the link with the ATLAS workload management system, PanDA  [11]. The overall architecture is shown in Figure  1. Jobs which are assigned to ATLAS@Home by PanDA are picked up by the ARC Control Tower, and sent to an ARC CE connected to the BOINC server. ARC CE copies the required input files from Grid storage to a staging area inside the BOINC server. ARC CE supports many batch systems and a new plugin for a BOINC "batch system" was written to allow injection of jobs as work units in the BOINC server.
At this point the job is ready to be picked up by a BOINC client running on a volunteer's PC. This client only has access to the BOINC server data staging area and no access to Grid storage or Grid credentials and so there is no chance of accidental or deliberate tampering with ATLAS data. Once the BOINC client has picked up a work unit and downloaded the necessary input files it starts a VM. The VM image itself is only downloaded once and reused for each work unit but each work unit requires of order 100MB of input data which is downloaded each time. When the image starts it automatically sets up the ATLAS software environment and starts the ATLAS job. The input data resides in a directory shared between the host and the VM. The result of the job is also written to this shared directory and once finished the BOINC client uploads it to the BOINC server staging area.
ARC CE then uploads the data from there to Grid storage. As the jobs are running on untrusted resources, it is very important to ensure that bad results are not uploaded to Grid storage and eventually used by physicists. There are therefore several validation steps in place. Firstly each result returned by a volunteer is checked to make sure the expected files and filenames are present. If not the job is failed and the volunteer receives no credit. At the end of each job a small metadata file is created with information on each output file such as size and checksum and after ARC CE uploads the file to Grid storage the checksums are compared to those in the metadata file. If they differ the job is rejected and retried. A clever volunteer could of course tamper with the metadata file to upload junk data, however at the next stage of the ATLAS task the results of the ATLAS@Home simulations are merged together into larger files.
Typically 10 results are merged into one file and this merging is done on regular Grid resources. As part of the merging each file is checked that it contains sensible data and if not the merge fails and the results are not used. A really clever volunteer with intimate knowledge of the ATLAS software could still in theory modify the event data to produce for example fake tracks in the detector but to mitigate against this, large-scale validation of the physics results is done comparing against similar tasks run on regular Grid sites. In many BOINC projects each work unit is sent to a few different hosts and the result is only considered valid if the results match byte for byte. However due to various random factors inside ATLAS software running the same job twice can never produce exactly the same result.
As the number of volunteers increased some scalability issues appeared, mainly related to the input and output data handling. Firstly, compression of the input files on the server before they were downloaded caused a large load on the server, however it provided no gain in the size of the data and so it was turned off. Secondly, for each job the input data file was copied to the BOINC server staging area but as the same file is used by many jobs this was changed to create hard links instead of copying, which greatly reduced the pressure on the disks. Lastly, the length of the job took some tuning: too short and the data transfer time becomes dominant, too long and the jobs may not finish on time on slow or heavily used computers. The way to control the length is through the number of events processed by the job and as of the time of writing the volunteers simulate 25 events per job, compared to 100 for the normal Grid jobs which typically run for around 12 hours on Grid resources.
Around October 2014 ATLAS@Home was moved to the BOINC platform used by the other CERN volunteer computing projects, thus removing the need to maintain a separate BOINC server and database. In addition a large storage area was provided which allowed extra headroom to expand the volunteer base. Figure  2  shows the number of running jobs in ATLAS@Home over the period of around one year, as seen by the ATLAS job accounting dashboard. A big jump can be seen in July 2014 corresponding to the point where ATLAS@Home was made an official BOINC project and from that point until the end of the year an average of between 2000 and 3000 running jobs were continuously running. At the start of 2015 this jumped up to 5000 jobs and until the time of writing the number of jobs stayed around this level. The sharp increase in early April 2015 is probably due to the publicity surrounding the restart of the LHC for Run-2.
Even so the capacity of ATLAS@Home is at the time of writing roughly equivalent to a large Tier-2 Grid site. The experience of dealing with volunteers has been both rewarding and challenging. Many volunteers expect a certain level of support in return for donating their CPUs and take the allocation of credit very seriously. One thing learned early on is that volunteers should always be given credit for their work units no matter what. This led to several changes in the workflow, for example still giving credit even if a work unit failed through a problem in ATLAS software, and never cancelling ongoing work units even if the jobs were cancelled by PanDA. The BOINC server comes with a web message board which acts as the main communication channel between volunteers and administrators. The ATLAS@Home message board is very active with several messages per day, but as the volunteers tend to help each other not every message requires administrators to answer.
System modeling Modeling language Modelica has been chosen to implement the models described above. As Modelica is an object oriented modeling language, it allows the realization of a complex system by simple gathering components  (Schiavo et al. , 2006). The construction of this model (Fig. 3 ) includes elements developed expressly for this application such as the plate component and selection of the position component as well as parts that belong to Dymola/Modelica library. The model of the system in Dymola is decomposed into a set of connected components; everyone is represented by a block containing the necessary information about the element, which can be changed by the user. The model can be divided into five main parts. The motor represents the dynamic excitation over the exterior surface of the plate.
Conclusions In this paper, we have proposed a new approach for the preliminary design of a mechatronic system based on an analytical method. We defined a model that allows the predictability of the vibrational behaviour of the system. The model has been developed using the modeling language Modelica/Dymola. To show the capability of the model to help designers in pre-dimensioning, we have analysed several parameters having significant influence on the vibration propagation. The possibility of modifing the geometrical characteristic, the parameters and the evaluation of possible missions will serve as a strong positive point for this new method. This modeling process will serve to meet the system requirements with acceptable risks and to establish the basis for proceeding with a detailed design.
The Cufflinks/Cuffmerge  [13]  method uses a more naive and straightforward approach, where transcripts are first predicted independently on each sample, before being merged (with some heuristics) in a unique set. In this paper, we propose a new method for isoform deconvolution from multiple samples. When applied to a single sample, the method boils down to FlipFlop  [21] ; thus, we simply refer to the new multi-sample extension of the technique as FlipFlop as well. It formulates the isoform deconvolution problem as a continuous convex relaxation of the combinatorial problem solved by CLIIQ and MiTie, using the group-lasso penalty  [23, 24]  to impose shared sparsity of the models estimated on each sample. The group-lasso penalty allows to select a few isoforms among many candidates jointly across samples, while assigning sample-specific abundance values.
Results and discussion We show results on simulated human RNA-seq data with both increasing coverage and increasing number of samples, with different simulation settings, and on real RNA-seq data. In all cases, reads are mapped to the reference with TopHat2  [10]. We compare FlipFlop implementing the group-lasso approach (1) to the simpler strategy of pooling all samples together, running single-sample FlipFlop  [21]  on the merged data, and performing a fit for each individual sample data against the selected isoforms. We also assess the performance of MiTie  [20]  and of the version 2. 2. 0 of the Cufflinks/Cuffmerge package  [13]. Performances on isoform identification are summarized in terms of Fscore, the harmonic mean of precision and recall, as used in other RNA-seq studies  [20, 22].
Influence of coverage and sample number The first set of simulations is performed based on the 1329 multi-exon transcripts on the positive strand of chromosome 11 from the RefSeq annotation  [30]. Single-end 150 bp reads are simulated with the RNASeqReadSimulator software (available at http://alumni. cs. ucr. edu/~liw/ rnaseqreadsimulator. html). We vary the number of reads from 10 thousand -10 million per sample (corresponding approximately to sequencing depth from 1 to 1000×) and the number of samples from 1 -10. All methods are run with default parameters, except that we fix region-filter to 40 and max-num-trans to 10 in MiTie as we notice that choosing these two parameter values greatly increases its performances (see Additional file 1: Figure A. 1 for a comparison between MiTie with default parameters or not).
Influence of hyper-parameters with realistic simulations The second set of simulations is performed using a different and more realistic simulator, the Flux Simulator  [31] , in order to check that our approach performs well regardless the choice of the simulator. Coverage and single-end read length are respectively fixed to 10 5 reads and 150 bp, and we run experiments for one up to five samples. We study the influence of hyper-parameters on the performances of the compared methods, and show that our approach leads to better results with optimized parameters as well. Hyper-parameters are first tuned on a training set of 600 transcripts from the positive strand of chromosome 11, which is subsequently left aside from the evaluation procedure after tuning. We start by jointly optimizing a set of pre-processing hyperparameters.
Experiments with real data We use five samples from time course experiments on D. melanogaster embryonic development. Each sample corresponds to a 2-hour period, from 0-10 h (0-2 h, 2-4 h,. , 8-10 h). Data is available from the modENCODE  [32]  website. For each given period we pooled all 75 bp single-end technical replicate reads available, ending up with approximately 25 -45 million mapped reads per sample. A description of the samples is given in table C. 1. Data from the same source were also used in the MiTie paper  [20]. Because the exact true sets of expressed transcripts is not known, we validated predictions based on public transcript annotations. We built a comprehensive reference using three different databases available on the UCSC genome browser  [33] , namely the RefSeq  [30] , Ensembl  [34]  and FlyBase  [35]  annotations.