dataesr/scientific-paragraphs-categorization huggingface dataset:
This has the advantage of forcing developers to consider the best interface for their new code, and to consider how to test that the source code performs its function correctly. There are then two discrete collections of code in each module of Chaste. The 'test' code makes use of the 'source', as if the source code were any other C++ library, and checks that it performs as intended. The 'source' never makes use of 'test', and only 'source' is compiled into a library for use in other modules (and third party programs). The test code is uploaded ('committed') to the central version control repository along with the source code that it tests. Upon each commit, all the tests are run in order to check that no functionality has been inadvertently broken ('continuous integration'). This ensures the code always performs as intended, and developers 'protect' their code from any future changes to either the code itself, or any code it relies on.
This approach does not guarantee bug-free code, but in practice makes bugs very rare. When bugs do occur, this is typically because functionality is expected that has not been fully tested, and the first step in the solution is to write more tests. Additional tests are run each night, which: check all of the standard tests for memory leaks; profile the speed of different parts of the code ; check for documentation on all source code; and check that every line of the source code is executed by at least one of the tests ('coverage'). Among all the coding practices we use, testdriven development is never abandoned, and is the feature most highly regarded by the development team, who commonly apply it to their other projects. Agile programming. Chaste is developed using an 'agile' development methodology, using many features of eXtreme Programming (XP)  [19].
Code Layout and Design Chaste provides libraries for code which is common to many computational biology problems. Here we briefly describe the components of the code and their capabilities. We will present and discuss example simulations, and the new scientific insight Chaste has enabled, in the Results section. N global -contains code for basic mathematics (including a random number generator), time stepping, checkpointing (saving and loading simulations) using the Boost serialization library  [20] , parallel vector classes, and code to handle warnings and errors. N io (input/output) -code for reading, writing and conversion of various file formats, including modules to handle the HDF5 scientific file format  [21] , which enables distributed data to be collated and stored in a single file.
N mesh -code for linear or quadratic tetrahedral meshes and vertex meshes; nodes, elements, boundary properties; mesh generation; mesh distribution using METIS/parMETIS  [22] ; readers and writers for Triangle/TetGen  [23, 24] , Meshalyzer, Cmgui (http://www. cmiss. org/cmgui) and VTK (Paraview)  [25]  formats. N linalg (linear algebra) -code which uses Boost uBLAS [20]   and PETSc  [26]  for vector and matrix operations. N ode -code for defining ODEs; solvers, basic finite difference schemes, the Sundials CVODE solver  [27] ; termination on root-finding capabilities. N pde -code for defining elliptic and parabolic second-order PDEs; parallel finite element solvers of generic coupled systems of PDEs (using mesh and linalg). N continuum mechanics -code for solving compressible and incompressible general non-linear elasticity problems.
These core components are used by two main application components that have driven Chaste development to date -cell based and heart, discussed in the Results section. Projects. 'Bolt-on' projects for individual studies using Chaste are supported via an interface to the build infrastructure. This also provides a link to our framework for test-driven development of code. Continuous testing can be utilised to ensure that your code maintains the capability to reproduce old results as it evolves. If common code occurs in more than one project, we encourage developers to migrate this code to the central Chaste repository, thus making it publicly available. Access to a project subversion repository hosted at Oxford, and integration into the Chaste wiki, is available for academic researchers upon request.
Results Here we provide some examples of the types of scientific problems that Chaste has been used to investigate to date. This section is structured around four examples, which can all be reproduced by running the tests in the project accompanying this paper. Each example is simple, so as to enable reproduction on a typical desktop PC. The code for each example is presented in a tutorial-style wiki pages at https://chaste. cs. ox. ac. uk/trac/wiki/ PaperTutorials/Plos2013. Details of visualization packages used to create the figures are contained on these wiki pages. Primary support is for the open source VTK visualization file format, although other formats can be output for specific types of simulation (for example the cardiac component also provides Cmgui and Meshalyzer formats).
An extension of vertex models to 3D is planned for future work. We have used Chaste to examine the suitability of these different modelling paradigms for the same biological problem, highlighting idiosyncrasies  [16, 37]. Our first example uses an off-lattice mesh based 3D simulation, coupled to a PDE , to simulate the diffusion and consumption of oxygen within a growing tumour spheroid. The PDE boundary condition is a fixed oxygen concentration at the spheroid surface; oxygen diffuses and is taken up by cells. In low oxygen conditions cells cease to proliferate, and in very low conditions in the centre of the spheroid they die (see Figure  1  and video S1), as observed in experiment. Our second example is taken from the crypt code component, developed to study intestinal crypts and the initiation of colorectal cancer.
This component includes code to define the intestinal crypt geometry, Wnt signalling pathway and intestinal cell-cycle models. In van Leeuwen et al. [28]  Chaste was used to predict monoclonal conversion in the colorectal crypt as a result of simple competition arising from the mechanics of the stem cell population. This prediction has since been confirmed experimentally  [38, 39]. We have used the Chaste off-lattice mesh-based simulations extensively to examine the concept and role of stem cells in crypt homeostasis  [31, 40] , as well as the contribution of mechanical effects to cell behaviour  [41, 42]. A hypothesis generated following Chaste simulations related to cellular extrusion in the crypt  [42]  was verified experimentally in independent investigations, published at a similar time  [43].
Availability and Future Directions Chaste is freely available to download from the website at http:// www. cs. ox. ac. uk/chaste. Releases 1. 0-3. 0 were under the LGPL v2. 0 licence, while v3. 1 and future releases are under the more flexible 3clause BSD licence, to facilitate use of the code by industrial partners. Currently, we are adding support for the following types of simulation: parallel cardiac electro-mechanics; His-Purkinje system in cardiac electrophysiology; lung mechanics; import of SBML models for signalling pathway and cell-cycle models; fluid flow for haemodynamics and airflow. We are investigating ways to make it easier for users to contribute code, and aim to support a Microsoft Windows environment in the next year.
C. Validation via proof-of-concept To validate the expected behavior of our implementation different networking scenarios have been tested (as described below) using the network emulation environment  [15]. MLC facilitates Linux Containers (LXC) to instantiate (depending on host CPU and memory resources up to hundreds of) virtual nodes, each with an isolated networking environment and employs Linux networking tools (like ip, tq, tc, ebtables, brctl) to create virtual links between node interfaces, including per link and link-direction specific packet loss. In order to validate the distributed application of nodeindividual metric functions, a purely hop-count based metric function was compared with the multiplicative and linkasymmetry aware TQ metric function. Resulting forwarding paths between nodes specifying different metric functions for the routing of their traffic have been compared using the ping record route option.
To justify this, we have measured the total and OGM-related overhead of BMX6 depending on the number of nodes in a network. Each measurement point, as shown in Figure  2 , represents the UDP overhead averaged over 100 seconds during the maintenance phase of the protocol. It could be seen that OGM-related overhead increases with roughly the same gradient as the total protocol traffic overhead. However, a slightly increased performance penalty is expected for the requirement of secure communication of protocol data with neighboring nodes. But again, this overhead will be caused by the Linux kernel and the employed IPSEC implementation since the validation, calculation, and configuration of security attributes for the IPSEC stack will be done as an outcome of the discovery phase. Recent hardware measurements published in the OpenWRT wiki  [28]  report that reasonable IPSEC-encrypted throughput performance can be achieved with current embedded devices.
For example using the AES256 cipher, encryption at up to 37Mbps is possible using a (AR7161) MIPS 24K CPU running at 680MHz. This is is enough to secure the comparatively small protocol traffic load between neighboring nodes (less than 3Kbps for a 200-nodes network) and even reasonable to encrypt user data. For the forwarding phase no additional overhead was expected nor measured. This is because the protocol only configures the kernel's routing table (as the outcome of the maintenance phase) and relies on the lookup of routing table entries for each packet as performed by the Linux kernel.
We investigate the mass, production and branching ratios of a 125 GeV Higgs in models with Dirac gaugino masses. We give a discussion of naturalness, and describe how deviations from the Standard Model in the key Higgs search channels can be simply obtained. We then perform parameter scans using a SARAH package upgrade, which produces SPheno code that calculates all relevant quantities, including electroweak precision and flavour constraint data, to a level of accuracy previously impossible for this class of models. We study three different variations on the minimal Dirac gaugino extension of the (N)MSSM.
JHEP06(2013)073 The LHC experiments have claimed the discovery of a new particle near 125 GeV  [1, 2]. Its production and decays make it a good candidate for the Higgs boson. However, more experimental data is needed for a precise determination of its quantum numbers and interactions to know if the Higgs sector is the Standard Model one, or an extended version, for instance as required in supersymmetric models. A clear indication of non-minimality would be a significant excess or deficit in at least one decay channel, but the Higgs mass itself can also be regarded as such, since it is somewhat high for the most natural version of the MSSM. This is one motivation for this work, in which we study the main properties of such a Higgs boson in models with Dirac gaugino masses. These have numerous virtues compared to their Majorana counterparts, not least that they allow for increased naturalness  [6, 23, 34, [37] [38] [39]  which is particularly important in the light of recent LHC SUSY searches  [40] [41] [42] ; but also that the direct production of gluinos is suppressed, loosening the bounds from direct LHC searches  [29, 31] ; they allow relaxation of flavour constraints such as due to Br(B → sγ)  [43] ; they preserve R-symmetry (allowing for simpler supersymmetry-breaking models) and can be motivated from higher-dimensional theories as being derived from an N = 2 supersymmetry in the gauge sector at some scale.
Higgs mixing involving the singlet induced by a Dirac Bino mass, however, then presents an intriguing opportunity: it allows the decays of the Higgs to b quarks and τ leptons to be suppressed while preserving the rate to W s and Zs, and an enhancement of the diphoton rate. We give an explanation of this and a discussion of the Higgs production and decay rates in section 5. Previous attempts to quantitatively study the Higgs sectors of Dirac gaugino models have been hampered by the lack of numerical tools to do so; until now only one-loop effective potential calculations of the Higgs mass have been possible. This is in contrast to the MSSM, where the leading corrections are known to three-loop order. However, with an upgrade of the SARAH package described in section 3, it is now possible to study models with arbitrary gauge groups and matter content: it can generate SPheno code which calculates all one-loop pole masses and tadpoles, which allows a much more accurate determination of the Higgs mass.
JHEP06(2013)073 which lends itself to four particularly interesting sub-classes of models, which we review in section 2. One such class of models is the "MSSM in disguise," where all the new scalars are too heavy to observe or mix substantially with the Higgs; this is a good toy scenario to use to test of the code, and we do just that. The SPheno code produced by SARAH can also calculate the branching ratios and production cross-sections of the Higgs, as well as electroweak precision observables such as ∆ρ and flavour constraints such as Br(B → sγ). We take full advantage of the latter in investigating the "MSSM without µ term"  [7]  in section 6, comparing the results for ∆ρ with approximations given in  [7]. Unfortunately those constraints in addition to those on chargino masses and the Higgs mass yield that model problematic.
Implementation in SARAH and SPheno For our numerical studies we have extended the Mathematica package SARAH  [48] [49] [50] [51]  to support Dirac gauginos. 1 This support includes an automatic derivation of all specific D-and fermion mass terms in the context of Dirac gauginos as well as the full two-loop RGEs using the results of ref. [39]. Both aspects are also covered in the presence of several Abelian gauge groups and kinetic mixing using the approach of ref. [52]. Afterwards we implemented our model and used the possibility of SARAH to create source code for SPheno  [53, 54]. For this implementation we used the most general setup allowing all possible superpotential and soft-breaking terms of eqs. (2. 2)-(2. 5). Also Majorana as well as Dirac mass terms could be present at the same time.
As further inputs for our studies we the soft-breaking terms as well as the superpotential couplings at the SUSY scale: the standard model gauge and Yukawa couplings are calculated at M SU SY using two-loop standard model RGEs from M Z  [55]. The obtained code including these boundary conditions was compiled with SPheno 3. 1. 2 and provides a fully functional spectrum calculator: the entire mass spectrum is calculated at one-loop using the full dependence on the momentum of the external particle. These calculations include the entire CP and flavor structure and, of course, also the mixing between MSSM fields and the new states. For a detailed discussion of the calculation of the loop corrected mass spectrum using SARAH and SPheno for extensions of the MSSM we refer the interested reader to ref.
[56]. We note that, in the absence of the theoretical JHEP06(2013)073 calculation, the code cannot include the two-loop corrections to the Higgs mass involving (Dirac) gluino masses that can be important in the MSSM and NMSSM. In those cases, the Higgs mass is usually increased by 2 to 4 GeV. Throughout we shall be conservative and allow a variation of ±4 GeV for the mass of the Higgs in the scans, but we expect that typically the shift will be positive. In addition, the produced SPheno version provides routines to calculate the decay widths and branching ratios for all SM superpartners and Higgs fields. In general, these are pure tree-level calculation. However, in the case of the Higgs particles the loop induced decays into two photons and two gluons are calculated. Here, not only the known SM or MSSM contributions are included but SPheno takes automatically the loops arising from all charged particles in the model into account.
This is a good approximation when the Higgs vev is small compared to the energy scales being integrated out; in this Comparison of effective potential method (labelled "approx m h ") with a parameter scan using SPheno code produced by SARAH. Parameters are given in the text; a searched was performed using the SPheno code, restricting to m h = 125 ± 4 GeV, and from the same input parameters for each model the one-loop Higgs mass is shown (note that this has a larger range). Only models with relatively low couplings λ S , λ T (roughly λ 2 S + λ 2 T < 1. 2). case, we shall consider integrating out the adjoint scalars, which is appropriate for the MSSM in disguise. We give the full expression for the coefficients λ i in appendix B, but an interesting limit is to consider B S = B T = 0 and neglect v, v S and the Dirac masses m Di ; then the contribution from the singlet and triplet scalars is  [23]  32π 2 λ 2 ⊃ 2λ 4 S log m 2 S v 2 + (g 4 2 -4g 2 2 λ 2 T + 10λ 4 T ) log m 2 T v 2 + 4λ 2 S λ 2 T m 2 S -m 2 T m 2 S log m 2 S v 2 -m 2 T log m 2 T v 2 -(m 2 S -m 2 T ) m 2 T →m 2 S -→ g 4 2 -4g 2 2 λ 2 T + 2(λ 4 S -2λ 2 S λ 2 T + 5λ 4 T ) log m 2 S v 2 (3.
2) where in the last line we show the limit that the scalar masses become equal. By performing a scan over parameters we can compare this approximation with the more accurate results from SPheno using the code produced by SARAH; we show the results with the choice of tan β = 50, m D2 = 600 GeV, first two generation sfermion mass squareds of 4 × 10 7 (GeV) 2 , third generation sfermion mass squareds 4 × 10 6 (GeV) 2 and scanning over  1. The expectation values v S , v T were set by the tree level minimisation equation with m 2 S , m 2 T = 2. 5 × 10 7 (GeV) 2 ; this resulted in values close to this for m 2 T , while the resulting one-loop adjusted values for m 2 S varied between 10 6 and 10 10 (GeV) 2. As can be seen from the figure, there is good agreement between the two, although of course the approximate effective potential calculation exhibits a wider variation of masses; that there is no apparent correlation is unsurprising, essentially reflecting the error margin in the effective potential method.
Higgs production and branching ratios It is now important to consider the production cross-sections and branching ratios of the Higgs. In our Dirac gaugino models there is a singlet scalar which may mix with the lightest Higgs state, so we shall consider the branching ratios into each channel taking into account the mixing, providing some approximate expressions and then comparing them to the output of the SPheno code created by SARAH. We shall use the standard definitions R i ≡ Γ(h → ii) Γ SM (h → ii) = A ii A SM ii 2 µ ii ≡ σ(pp → h) σ SM (pp → h) BR(h → ii) BR SM (h → ii) (5. 1) where A ii is the amplitude.
12) is m2 S = - √ 2t S + v 3 0 v S (7. 1) and, expecting from naturalness and RGE running  [39] t S ∼ v 3 0 ∼ v 3 , v S ∼ v, m2 S ∼ v 2. There may thus be substantial mixing between the singlet and original "h" eigenstate; the size of Bµ term then controls the amount of "H" in the lightest Higgs mass eigenstate. Moreover, the singlet couples to the gauginos via the coupling λ S , which, if m D2 is not small, will be predominantly Higgsino-like. This then offers the possibility of realising the scenario considered in section 5. 1. We have therefore conducted a scan over a portion of the parameter space of these models, concentrating on models with a small component of mixing between h and H but substantial S 11 and S 31 components, using the SPheno code produced by SARAH. tan β was taken to be 1.
Figure1. Comparison of effective potential method (labelled "approx m h ") with a parameter scan using SPheno code produced by SARAH. Parameters are given in the text; a searched was performed using the SPheno code, restricting to m h = 125 ± 4 GeV, and from the same input parameters for each model the one-loop Higgs mass is shown (note that this has a larger range). Only models with relatively low couplings λ S , λ T (roughly λ 2 S + λ 2 T < 1. 2).
Acknowledgments We thank  Jong Soo Kim ,  Nicolas Bernal  and  Werner Porod  for fruitful discussions. MDG was supported by  ERC  advanced grant  226371. He would like to additionally thank  Veronica Sanz  and  Michael Trott  for helpful discussions, and  Chris Wymant  for pointing out some typos. KB is supported in part by the  European contract "UNILHC "  PITN-GA-2009-237920.
We have compared several routines to represent spheres and links between them, using either built-in Unity3D features or our own implementation. These developments resulted in a stand-alone viewer capable of displaying molecular structures, surfaces, animated electrostatic field lines and biological networks with powerful, artistic and illustrative rendering methods. We consider this work as a proof of principle demonstrating that the functionalities of classical viewers and more advanced novel features could be implemented in substantially less time and with less development effort. Our prototype is easily modifiable and extensible and may serve others as starting point and platform for their developments. A webserver example, standalone versions for MacOS X, Linux and Windows, source code, screen shots, videos and documentation are available at the address: http://unitymol.
autodesk. com/maya/), Cinema 4D (http://www. maxon. net/products/cinema-4d-studio. html) or Blender (http://www. blender. org/). Scientific projects associated to these programs include ePMV  [4] , Molecular Maya  [5]  and BioBlender  [6]. Using such tools for animation is particularly beneficial for teaching as well as for communicating with a broad public, even leading to new discoveries  [7]  and valuable insight by combining experimental data and modelling  [8]. Unlike the emerging spread of tools from the movie industry, the use of software to develop games remains largely unexplored in molecular graphics and modelling, despite its enormous potential. For many years, game developers have gathered routines and frameworks that can be reused for a wide range of games. These code blocks have been aggregated to provide toolkits, called game engines, embedding all the components required to create a game in one package  [9].
Current needs include the ability to display hundreds of thousands of distinguishable elements in interactive time, using classical representation schemes. To provide a realistic scenario, inspired by current research, we have implemented our own visualization algorithm based on latest hardware capabilities such as programmable Graphics Processing Units (GPUs)  [10]. The aim was to identify eventual restrictions imposed by the game engine programming environment. A user-friendly interface is required to facilitate navigation and interaction with virtual objects. In order to touch a wide audience, multiple platforms should be supported without the need to develop specific ports -ideally computers on Windows, MacOS and Linux operating systems, web pages, handheld devices such as smartphones and tablets.
Most of the available game engines provide such features as well, but at different levels of development easiness. We have chosen to test the Unity3D game engine (http:// unity3d. com/) for its ability to deploy multi-platform applications with minimal programming effort. Furthermore, Unity3D provides an easy-to-use interface to develop 3D graphics applications using JavaScript, Boo -a python derived language -or C# code. Unity3D includes advanced functionalities to fully use the capacities of recent programmable graphics cards. This is possible employing optimized Cg functions  [11] , dedicated for Nvidia graphics cards, or GLSL (OpenGL Shading Language) code, a more universal language, which can be used on all recent graphics cards as well as on mobile devices  [12]. The developer community is very active and helpful in providing example code and expert answers when technical problems are encountered.