dataesr/scientific-paragraphs-categorization huggingface dataset:
Accessing Data Files For structural data we use the Protein Data Bank  [15]  format. Coordinate files can be imported from local storage or can be downloaded directly from the PDB server by entering their molecule ID. Due to security restrictions in the Unity3D web plugin, files have to be loaded through an intermediate server rather than from the local disk. After fetching files from the PDB or the server, they can be used by the web application. This restriction does not apply to the standalone viewer. PDB files are parsed to extract atom information such as atom type, residue name, residue id and coordinates. The molecule topology is built by using typical interatomic distances to detect bonds. Surfaces are generated either externally as meshes in the Wavefront OBJ format (these files contain vertex and face information used to reconstruct a 3D mesh), or internally using a density grid isosurface approach.
Electrostatic potential grids computed by APBS  [16]  (or other tools) and stored in OpenDX format can be read for iso-surface visualization or be pre-treated using the BioBlender pipeline to generate Json files representing field lines. These files describe point coordinates for each field line to be animated. Network topologies are represented using extensible Graph Markup and Modelling Language (XGMML) format that can be obtained from Cytoscape (http://www. cs. rpi. edu/ research/groups/pb/punin/public_html/XGMML/)  [17]. XGMML files are parsed to extract id, name, position, size, colour and topology of nodes.
Graphical Methods Used We have tested graphical methods available in Unity3D as well as our HyperBalls representation based on ray casting  [13]. The purpose of implementing HyperBalls was to evaluate how difficult it is to port previously developed code to Unity3D and whether this approach facilitates and speeds up the creation of a molecular graphics application. By implementing a molecular surface generation routine based on the classical marching cubes algorithm, we provide an additional proof of the generality of the game-engine approach for visualization applications. Built-in graphical primitives. Unity3D provides an optimized set of graphical primitives for rendering. We use triangulated spheres, triangulated cubes and lines. Spheres and cubes display atoms (for molecular structures) or nodes (for networks); links between them are rendered using lines (see Fig.
1-C ). The Unity3D framework enabled us to implement such a graphical method by integrating GPU code -so called shaders -to be run on the graphics card (as Cg or GLSL instructions). We implemented HyperBalls using built-in Cg functions. To create the representation, it is necessary to generate envelopes using cubes and parallelepipeds to define atom and bond primitives, respectively. Then, we represent spheres and hyperboloids within these envelopes using ray casting. Starting from this previously published implementation, we were able to quickly add improvements to it, such as the lit spheres shading described below. Visualization of electrostatic potential. Electrostatic potential visualization was implemented in UnityMol either as isosurfaces or as animated particles following field lines.
Alternatively, UnityMol is able to generate a Gaussian molecular surface. An atomic density grid is computed by adding Gaussian distributions originating at the atom positions as discussed in  [24]. This technique has subsequently been used in the Yasara software  [25]  and more recently also in the VMD program  [26]. Then, the Marching Cubes algorithm  [27]  is applied to the density grid in order to generate an isosurface. The user can control the coarseness of the surface by changing the surface threshold. While the process is fairly fast for molecules up to 20 000 atoms, more optimizations are to follow for larger systems. All types of surfaces can be cut according to fixed or moving planes. The interior of the molecule is filled by a uniform colour to enhance the user's impression of cutting a solid object.
All the visible normals for one viewport can be retrieved on a theoretical half-sphere located at the centre of the screen. Thus a lighted sphere, or lit sphere, depicted in 2D contains all the information required to construct a lighting model. Sloan et al. [14]  used this principle to light 3D meshes by mapping pixel normals with a 2D texture representing a sphere. In UnityMol, we implemented this approach for triangulated meshes and Hyper-Balls using shader programs to compute the normal for a pixel and retrieve the colour value at the corresponding coordinates on the texture. This value can be used as is or blended with other colours or textures to combine different rendering effects. A few lit spheres are included as UnityMol program resources. The user can choose a texture for surfaces and HyperBalls representations using the GUI.
Hardware and Software Implementation Development, benchmarking and testing were carried out on a Mac Pro computer with a quad-core Intel Xeon 3 GHz processor, 8 GB of memory, an NVIDIA GTX 285 graphics card, running 64bit Mac OS X 10. 6. Results presented in this article are mostly based on the 3. 5 version of Unity3D. All source code is implemented using C# and Cg languages built into Unity3D and is available on the sourceforge project website http://unitymol. sourceforge. net.
Performance of Different Graphical Methods In this section, we evaluate several Unity3D features on a simple test case and go on to determine the efficiency of the most promising features on a wider range of molecular structures. We then compare these features to our HyperBalls implementation. Comparison for a simple test case: ferrocytochrome C. We used the molecule ferrocytochrome C  [31] , PDB ID: 1KX2, as a test case to compare the rendering approaches implemented in Unity3D. This protein is composed of 1 249 atoms and 1 113 bonds, a common size in the PDB. We evaluated four methods to render atoms (see Fig. 1 ): a particle system, triangulated spheres, triangulated cubes and HyperBalls spheres. We also tested three methods to display bonds: cubes, lines and HyperBalls hyperboloids. The use of cubes is not of interest for representing atoms but it provides reference data for benchmarks allowing us to compare against the creation of simple graphical primitives with Unity3D.
Molecular Features Visualization and Artistic Rendering Electrostatic field lines visualization. Recently, Andrei et al. have developed an animated representation to depict electrostatic field lines using the Blender program  [18]. This visualization is particularly appealing and useful to represent the pathways that a charged molecule may follow guided by otherwise invisible electrostatic interactions. Unfortunately, the previous implementation is specific to the Blender package, which has a steep learning curve. Furthermore, it can only be run in an Internet browser window. We have reused this type of animation in the UnityMol viewer so that field lines can be visualized in the standalone version as well as in Internet browsers (see Fig. 3 ). Interactive features enable the user to change the graphical aspect of the field line animation.
Unity3D provides routines to use game peripherals such as joypads and joysticks. These game controllers can assist the user in navigating the scene as illustrated in Movie S1 described in File S1. UnityMol supports the joystick for control functions such as navigation via the integrated manipulator, selection of atoms and bond visualization modes, globally changing atomic radii and more. In the future, we plan to extend these functionalities using the Nintendo Wiimote, the Leap Motion and the Microsoft Kinect devices. In Unity3D, it is straightforward to create a GUI without using a dedicated and potentially complex toolkit. We used built-in mouse picking functions to highlight selected atoms and access information (such as atom type, residue, etc. ) or calculate distances between atoms. The UnityMol GUI, main program features and general usage of the software are described in Fig.
Reusing Components for Speedy Development of a Systems Biology Application A particular benefit of a game engine is its modularity and the reusability of the generated routines and scripts. The use of an integrated intuitive editor facilitates the development of applications without writing numerous lines of code. It is possible to position 3D objects in the scene and apply scripts and graphical functions directly via the Unity editor. To illustrate this feature, we have adapted our molecular viewer to represent generic biological networks in 3D. To implement this network viewer (embedded in the demo), we have adapted the file parser to read XGMML (extensible Graph Markup and Modelling Language) format obtained as output of the CytoScape program  [17]. The graphical primitives to represent atoms were used to depict network nodes while primitives displaying interatomic bonds are reused to model network edges.
UnityMol a Graphical Application to Gather Molecular, Network and Electrical Field Lines Visualization We have gathered recently developed graphical tools in an easy to use distributable software that provides a unique combination of functionalities absent from other publicly available viewers. We have implemented the recently developed HyperBalls representation  [13]. In comparison to the original HyperBalls program, it is now possible to dynamically adapt the visual aspect to the user's liking by continuously adjusting radius and shrink factor parameters via the graphical user interface. Furthermore, animation and artistic rendering enabled us to enhance classical molecular representations such as surfaces and electrostatic field lines. Additional visual effects allow the user to intensify a scene and create original images.
We are working to improve this part. The new version of the Unity3D game engine released a few weeks ago has already improved the display performances (see Table  2 ). We hope that future versions of Unity3D driven by the increasing need of video games for GPU power -to display new visual effects and accelerate interactivity -will help to further improve the visual performances of UnityMol. It should be emphasized that we present here a first version of our approach and we will continue work to develop more efficient algorithmsespecially representations using the HyperBalls approach. We hope that our program may interest the community of computer scientists and game designers who may provide valuable help to overcome this type of limitations. In addition to molecules, we have implemented a 3D visualization of biological networks from Cytoscape  [17]  where the depth can be adapted to avoid overlap between different nodes.
For example, when visualizing field lines, the editor mode enables the user to select and delete field lines that are unwanted and hence fine-tune the scene (as in Fig. 3-C ), despite the fact that we never explicitly implemented such a functionality (see Fig. S5  in File S1). This feature can be particularly useful to prototype new 3D molecular representations. Furthermore, instead of the need to recompile programs such as VMD or PyMol to see the results of modifications, using the Unity3D engine helps developers to modify, test and debug their code interactively using the editor window, on-the-fly compilation and the runtime debugger of MonoDevelop, the integrated development environment furnished with Unity3D. These features clearly help to simplify the visualization development due to a rapid and interactive trialand-error test cycle.
Furthermore, Unity3D provides simplified access to low-level graphics hardware functionalities that are usually not exposed in the APIs of existing programs such as VMD or PyMol. Thus, such a wide range of control by the user could be seen as a new paradigm for scientific software development and presents a clear rupture with current approaches used for molecular visualization tools. At best, common packages provide scripting access to selected functionality to the user, otherwise programming know-how is required to delve directly into the application source code -if it is available. In the context of open computer programs  [34] , this approach provides users and developers not only with access to the source code but also with a very accessible interface (i. e. the editor) to examine the underlying science and implementation of the program.
UnityMol as a Platform for Prototyping Scientific Tools We have described how to use a game engine such as Unity3D to create a viewer for molecular structures as well as for biological networks. During the development of these tools, it became obvious that a game engine facilitates the development of scientific applications: the editor window provides an interface to position 3D objects and assist with the attribution of functionalities, e. g. implemented by a script, by dragging an icon onto the target object. Thus, the amount of lines of code to be written is rather limited and can in large parts be hidden for non-experts. Development is further facilitated by support from a very active Unity3D user community (see http://unity3d. com/support/ community. html), which provides assistance to novice developers (this is also true for many other game engines).
In particular the existing internet forums and answer sites are a good source of information with many pieces of code almost ready-to-use. For example, the original lit sphere shader was adapted from the official Unity3D forum. Several screen-space visual effects and the file browser are user contents as well. For non-expert programmers the availability of such resources speeds-up the development cycle and softens the learning curve of the programming environment. Many common visualization techniques are already implemented and provided with Unity3D such as triangulated spheres, lines, cubes and more, as well as a physics engine and built-in functions to manage different types of controllers. While the development tools are only available on Mac and Windows, stand-alone applications can be deployed for the Linux platform as well.
There are some specific limitations in the free version of the Unity3D program (such as less visual effects). Buying a professional license provides access to special features or dedicated functions for systems such as game consoles or smartphones. Work is in progress in our group to explore these additional features and deploy UnityMol on new platforms such as mobile devices. We only scratched the surface of many features that can be further extended to develop efficient programs. For example, the physics engine could be exploited to create spring networks, molecular dynamics and flexibility. Using this physics engine combined with joystick or Wiimote controllers, it would be straightforward to develop simple tools for interactive docking. Our immediate plans are to extend UnityMol with practically important aspects for the biophysical community such as molecular dynamics trajectory loading and analysis.
There may be an enormous potential in such scientific ''games''. Using adequate tools such as game engines may facilitate the creation of such games by scientists. Starting from the code base that we provide, it would be easy for a game designer working with Unity3D to create simple games for education or beyond. Furthermore, using dedicated game controllers such as the Wiimote and Kinect, will allow users to interact with molecules in a more natural manner. This may be a good solution to further implicate young people in classroom demo presentations or museum exhibitions. Interactivity is equally important for researchers to evaluate their hypotheses or develop new ones on live computer models by being able to ''play'' with them. Currently, interacting with models using tools dedicated for the movie industry is a difficult task given that making an animation may require several weeks, months or more  [7].
The possibility to easily develop programs to automatically target major platforms (Linux, MacOS X and Windows) as well as media such as internet or video game consoles and nomad hardware (smartphones and tablets) reinforces the impact of this approach to touch a broad audience. The easiness of developing new visual methodologies -such as lit spheres presented in this paper -using the editor window can help developers designing new visual paradigms which are nowadays a priority to deal with challenges of data visualization  [46]. These new developments can then be more easily included in well known molecular viewers such as VMD, PyMol, etc … Even if this first version is not as powerful as such molecular viewers, it opens a new way for developing visualizations and may pave the first step towards a convergence between game design and molecular visualization research.
Deriving glacier outlines from satellite data has become increasingly popular in the past decade. In particular when glacier outlines are used as a base for change assessment, it is important to know how accurate they are. Calculating the accuracy correctly is challenging, as appropriate reference data (e. g. from higher-resolution sensors) are seldom available. Moreover, after the required manual correction of the raw outlines (e. g. for debris cover), such a comparison would only reveal the accuracy of the analyst rather than of the algorithm applied. Here we compare outlines for clean and debriscovered glaciers, as derived from single and multiple digitizing by different or the same analysts on very high-(1 m) and medium-resolution (30 m) remote-sensing data, against each other and to glacier outlines derived from automated classification of Landsat Thematic Mapper data.
But even if strictly followed, these rules lead to some variability in interpretation of the 'true' glacier extent, as the identification of debris-covered glacier parts, seasonal snow, dead ice or ice in cast shadow can be challenging  (Racoviteanu and others, 2009). In this regard, finding a 'ground-truth' or reference dataset that can be used to validate glacier outlines is also non-trivial. It is generally assumed that glacier extents derived from coarser-resolution sensors can be validated by comparing them to results from a higher-resolution sensor (e. g. 30 m Landsat Thematic Mapper (TM) with 1 m Ikonos). Though this might be true in a general sense, several constraints have to be considered to avoid invalid comparisons (cf. Svoboda and Paul, 2009) : 1. the images from both sensors should be acquired around the same date (week) within a year to avoid changes due to different snow conditions; 2.
at a higher spatial resolution, new details on the surface become visible that require a different interpretation; 3. the common higher-resolution sensors (including aerial photography) lack a spectral band in the shortwave infrared (e. g. Landsat TM5), so the base data for the interpretation are different; 4. a lower contrast between glacier ice and the surrounding rock in the visible and near infrared (VNIR), as available from high-resolution sensors, can degrade the interpretation substantially (i. e. the perimeter can be virtually invisible); and 5. for objects with a shape that is more complex than a simple square (i. e. glaciers), the area also varies with spatial resolution of the image. This has to be considered when glacier sizes derived from high-and lower-resolution sensors are compared (e.
g. Paul and others, 2003). In practice, it is difficult to rule out all the above limitations, and the 'validation' with a higher-resolution dataset can easily be considered scientifically unsound. When the above-mentioned differences in interpretation of glacier extent by different analysts are also taken into account, reporting accuracy correctly is indeed challenging. Another important point is the comparison of automatically derived glacier outlines with manually digitized ones. Here two issues must be considered: (A) apart from a few regions without lakes and debris-covered glaciers, the automatically derived glacier outlines are usually also corrected manually (by visual interpretation of the satellite image), and (B) manually digitized glacier outlines differ in each digitization (even when performed by the same person), as the degree of generalization (e.
STUDY REGIONS AND DATASET DESCRIPTIONS The two study regions are located in the eastern Chugach Mountains, Alaska, USA, and in various parts of the European Alps (Switzerland, Austria, Italy), as shown in Figure  1. The major selection criteria for the regions and the selected glaciers were: variability with regard to glacier size and mapping challenges (debris, shadow, snowfields), a feasible number of sites and glaciers to facilitate wide participation, scenes from the end of the ablation period with seasonal snow close to a minimum, availability of high-resolution scenes with good contrast in Google Maps TM , a good temporal coincidence or at least comparable snow conditions of the high-and lower-resolution images, and well-defined glacier entities in all images used for multiple digitization.
To use them for the digitization of glacier outlines, their upper left corners were iteratively geocoded by changing the coordinates in the tfw (tif world) file until they matched with the respective (also orthorectified) Landsat scene (level 1T product from the United States Geological Survey). The pixel size was derived from the scale bar on each image. Compared to the pixel size of Landsat and at the scale of individual glaciers, we found that the resulting geolocation accuracy was sufficient (i. e. no systematic shifts were observed). The images for the three regions were provided in Geotif format along with a tfw file. The screen shots did not always have the original resolution of the high-resolution datasets and included local artifacts (e. g. from jpg compression). However, this does not impact on the value of the round robin, as all participants used the same datasets and a variety of spatial resolutions and challenging mapping conditions should be investigated in the round robin anyway.
Instructions for the participants To guide the digitizations of the participants, detailed instructions were provided in a short document describing the reasons for the round robin, the datasets, how to perform the work and a feedback form. Internal tests revealed that this part of the round robin would take $4-6 hours for one round of digitization. The participants were free in working with their specific software, the magnification applied during digitizing and the level of detail (the number of vertices digitized per polygon). They were also allowed to check for details with Google Maps TM or other sources of high-resolution imagery and no time limit was given. All participants were asked to report meta-information (e. g. time taken, additional sources used) in a feedback form. The interpretation of the glacier extent as seen on the respective image was the core of the exercise, so no additional advice was provided for that.
Glacier mapping with Landsat TM The glacier outlines from TM were derived with the wellestablished band-ratio method (e. g. Albert, 2002; Paul and others, 2002)  and have been created for the test region O ¨tztal Alps in an earlier study  (Paul and others, 2011). Glaciers were classified when the raw digital numbers of band TM3 were 1. 8 times higher than in TM5 (TM3/ TM5 > 1. 8). Apart from one glacier with debris cover in this selection, the outlines were used as is (and not adjusted for the round robin) to have the required independence of the datasets. For the glacier with debris cover, the outline was corrected afterwards to have a comparable value. Of course, this corrected outline is now different from the fully automatically derived extents, and the difference from the fully manually digitized extents stems more from the variability in interpretation rather than from the accuracy of the automated mapping.