dataesr/scientific-paragraphs-categorization huggingface dataset:
To meet the computational and flexibility requirements of future 5G networks, the signal-processing functions of baseband stations and user equipments will be accelerated onto programmable, configurable and hardwired components (e. g. , CPUs, FPGAs, hardware accelerators). Such mixed architectures urge the need to automatically generate efficient implementations from high-level models. Existing model-based approaches can generate executable implementations of Systems-on-Chip (SoCs) by translating models into multiple SoCprogramming languages (e. g. , C/C++, OpenCL, Verilog/VHDL). However, these translations do not typically consider the optimization of non-functional properties (e. g. , memory footprint, scheduling). This paper proposes a novel approach where system-level models are optimized and compiled into multiple implementations for different SoC architectures.
Section 6 concludes this paper and discusses our future work. In the context of UML-based MDE, code generation for SoCs is based on a direct translation of UML modeling assets into constructs of a target language (e. g. , a UML block becomes a C function), according to precise translation rules  (Vanderperren et al. , 2012). Many works propose one-to-one translation rules for SoC languages such as C  (Nicolas et al. , 2014) , C++  (Ciccozzi et al. , 2012) , Verilog  (Bazydlo et al. , 2014) , VHDL  (Moreira et al. , 2010)  and Sys-temC  (Mischkalla et al. , 2010; Xi et al. , 2005; Tan et al. , 2004). A representative work that uses oneto-many translation rules is Gaspard2 (Graphical Array Specification for Parallel and Distributed Computing)  (Gamatie et al. , 2008; DaRTteam, 2009) , a MDE SoC co-design framework based on MARTE.
Thanks to the notion of Deployment, in Gaspard2 an Elementary Component (a resource or a functionality in a MARTE model) is related to implementation code that specifies low-level behavioral or structural details in a usual programming language (e. g. , C/C++) for formal verification, simulation, software execution and hardware synthesis. Executable UML (xUML) or executable and translatable UML (xtUML)  (Mellor and Balcer, 2003; Mellor and Balcer, 2002)  defines both a software development methodology and a highly abstract software language that combines a subset of UML's graphical notation with executable semantics and timing rules. When "programming" in xUML, a system's application is captured in the metamodel. The model compiler comprises some library code and a set of rules that are interpreted against the metamodel to produce text for a target SoC (e.
While  (Floch et al. , 2011)  tries to bridge the gap between model-based optimizations and abstract representations of pure software systems, our work transforms system-level models that also include hardware components (e. g. , on-Chip RAM memories). The landscape of industrial tools that generate SoC implementations of signal-processing applications from models is also very rich, e. g. , National Instruments LabVIEW Communications System Design  (Labview, 2017) , MATLAB (MAtrix LABoratory)  (Mathworks, 2017) , GNU Radio  (GNURadio, 2017). While our compilation approach targets multiprocessor architectures, these tools translate models that describe the functionality of a system to be executed onto single-processor architectures where data are processed onto a single unit.
g. , Xilinx Vivado High Level Synthesis). In case of pure software implementations, the translator can be a traditional programming-language compiler (e. g. , GNU/gcc/g++, clang, TurboC). The lower part of Fig. 1  (dotted boxes) represents all of these possible implementation types. The compiler proposed in Fig. 1  essentially performs a series of model transformations: model-to-model in the front-end and middle-end, model-to-text in the back-end. These transformations should be formally described in order to guarantee that the output model/text of the transformation retains the semantics of the input model. However, these formal descriptions depend not only on the formalism of the input PIM-PSM and on the language of the output target program. They also depend on the formalism of the Intermediate Representations.
As stated in  (Floch et al. , 2011) : "Since compiler IRs are abstractions used to represent programs, they are by essence models (an instance of IR is an abstraction of the given source code). In this context, the grammar of the source language, or more often the structure of IR, becomes the metamodel". An implementation of the compiler architecture shown in Fig. 1  results in a tool that can be used to target, at the same time, different implementation types for multiple architectures. Given the pair PIM-PSM and a library of implementation-specific functions, an implementation to be executed in software (e. g. , for execution on a control processor, for emulation purposes) is obtained by using a traditional compiler (e. g. , GNU/gcc) for software languages. By changing the translator to a CAD tool, the same system can be realized in terms of both hardware and software components (e.
Front-end The front-end in Fig. 2   by a MDE-to-compiler plugin that allows the compiler to be independent of the specific modeling language used by the input MDE. In this paper, the PIM-PSM is taken from the open-source MDE framework TTool/DIPLODOCUS  (Apvrille et al. , 2006; Apvrille, 2008). The plugin scans and parses a PIM-PSM described in. xml format by TTool/DIPLODOCUS and passes this description to the Graph generator (Fig. 2 ). The latter converts a UML-SysML pair PIM-PSM  (Apvrille, 2008)  into a SDF graph. In a SDF graph, nodes (actors) represent processing entities interconnected by a set of First-In First-Out (FIFO) data queues. An actor starts execution (firing) when its incoming FIFO(s) contains enough tokens, it cannot be preempted and produces tokens onto its outgoing FIFO(s).
The number of tokens consumed/produced by each firing is a fixed scalar that is annotated with the graph edges. As actors have no state in the SDF Model of Computation (MoC), if enough tokens are available, an actor can start several executions in parallel. For this reason, SDF graphs naturally express the parallelism of signal-processing applications and can be statically analyzed during compilation for memory allocation optimizations. A PIM in DIPLODOCUS is a SysML Block Definition diagram that captures the computation of a signal-processing system as well as their data and control dependencies. The internal behavior of each operation is further described with a SysML Activity diagram. As the execution of a SDF graph is not influenced by the internal variables of actors, we ignore the Activity diagrams of a DIPLODOCUS' PIM and only consider the Block Definition diagram.
Moreover, as we are interested in optimizing the memory footprint of a signal-processing system, we only consider blocks in the PIM that are connected by data channels. Therefore, we produce for each block and data channel in the PIM a SDF actor and an edge, respectively. Each actor in the resulting SDF graph G is annotated with the execution unit where is has been mapped in the PSM. A PSM in TTool/DIPLODOCUS is a UML Deployment diagram that specifies a platform's topology, its units (e. g. , CPU, Direct Memory Access -DMA, memory) and each unit's performance characteristics (e. g. , number of cores for a CPU, number of channels for a DMA). UML artifacts are used to map operations onto the platform's units.
Middle-end In this version of the compiler's middle-end, we propose a system-level memory optimizer that minimizes the footprint of the logical buffers associated with the data channels among computations in a SysML PIM from DIPLODOCUS. In this work, we differentiate between logical and physical buffers. A physical buffer defines a range of memory addresses of a physical memory device (e. g. , a Random Access Memory -RAM). A logical buffer, instead, is a virtual address space that can be mapped onto one or multiple physical buffers. Our optimizer implements a variant of the allocation techniques presented in  (Desnos et al. , 2014)  that we adapted to allow the sharing of input and output buffers of actors, similar to one of the memory reuse techniques presented in  (Desnos et al. , 2016).
Back-end The back-end in Fig. 2  translates G into a C program. Each actor (operation) in G is translated into 4 implementation-specific C routines for initialization, execution, scheduling and clean-up purposes (Fig. 2 ). Initialization and clean-up routines are called once, when the program starts and terminates, respectively. These routines manipulate the software data structures that are needed by processing units in the target platform to prepare and clean up the execution of an actor in G. Scheduling and execution routines are called to test the eligibility to run an op-eration and to trigger its execution on the hardware, respectively. The memory bound determined by Algorithm 1 is used by the back-end to allocate shared physical buffers for operations mapped to the same execution unit.
CASE STUDY We used the model compiler described in this paper to produce executable code for two target platforms, from the UML/SysML model of a 5G decoder that we designed in DIPLODOCUS for the uplink (SC-FDMA), single antenna case, Physical Uplink Shared channel (xPUSCH), based on  (Verizon, 2015). The algorithm of the signal-processing operations (application) that compose the 5G decoder is shown in Fig. 3. We captured this application in a TTool/DIPLODOCUS' PIM with a SysML Block Definition diagram containing 10 SysML Composite Components (1 source, 1 sink and 8 blocks, one for each of the signal-processing operations in Fig. 3 ). Each Composite Component contains 2 SysML Primitive Components that model the configuration and the data-processing of a given operation. By way of example, Fig.
4  shows the TTool/DIPLODOCUS SysML Composite and Activity diagrams for operation 64QAM Demodulation. Table  1  lists the data produced and consumed by operations in Fig. 3 , given an input subframe (14 OFDM symbols and 41 LDPC code blocks). In our final implementations, the complex samples listed in Table  1  are represented on 32 bits. subsystem where the processing of data is accelerated. Here, a PE (Processing Element) block models the architecture of a DSPU in Embb or a hardware IP block. The TTool/DIPLODOCUS model of a PE's internal architecture is depicted in Fig. 6. The righthand side of Fig. 5  captures the control part of our two target platforms: a CPU and a memory units interconnected by a bus unit. To compile executable code, we instantiated, in TTool/DIPLODOCUS, a PSM model such as the one in Fig.
5  that contains two Processing Elements for Embb and one Processing Element for the IP-based platform. The mapping information corresponding to these PSMs is illustrated in Fig. 7. to a given execution unit. In the case of Embb, according to the mapping in Fig. 7 , each set of logical buffers {A out , F in F out , H in , HI}, {B in , BC, CD, DE, E out } and {G in G out } in Fig. 7  is merged to share a common physical memory area. Given the sequential nature of the scheduling of these operations, the size of each of the three memory areas is equal to the size of the largest logical buffer: I in , B in and G out. The target C program produced by the back-end is based on a library of 371 implementation-specific functions. For the IP-based platform, according to the mapping in Fig. 7 , the middle-end optimizes the memory footprint of two sets of logical buffers: {AB, BC, CD, DE, EF} and {G in G out } in Fig.
The target program translation In the case of Embb, the target C program is translated into an executable with GNU/gcc v. 5. 4. 0 crosscompiled onto Ubuntu v. 16. 04. 4. This executable (a pure software implementation of the input models) runs on the main CPU in Fig. 5  as a user-space application for Linux v. 4. 4. 0-xilinx. In the case of the IP-based platform, we translate the target C program with Xilinx SDx (Xilinx, 2017) into a mixed hardware-software implementation. The output of the Xilinx SDx translation process are a Linux image and an. elf file for the software part of the implementation, to be executed by the CPU of the programmable subsystem. The executable for the hardware part of the implementation is a FPGA bitstream. The latter is loaded into the target FPGA's configurable fabric by a Linux image that runs onto the FPGA's control processor (not represented in our models).
Simulation of electrospinning on MATLAB Jet's trajectory is simulated using the software MATLAB R2017b Differential equations of motion are transformed into a state space notation consisting of first order differential equations that is used as input for MATLAB's ode45 solver. To do so, all the position velocity and tension coordinates of the system are transformed to a new state vector, called U. Note that the name of U is arbitrary. The size of U depends on the number of beads present in the system.
( ). 11 18 1 8 1 8 T u u u u u u i i N N U = (60) Based on equations (  54 ), (  55 ), (  56 ) and (  57 ) applied to  ̅ ,+1 , and  ̅ -1, , time derivatives of all the terms of the state vector are given. Those derivates depend on elements of the state vector. Thus, we can use the ode45 operator of MATLAB to solve the equation and obtain the state vector, and thus the trajectory of each bead. According to this model, some assumptions have been made concerning the first and the last bead. As the bead i undergoes the forces of bead i+1 and i-1 and for the first bead there is not bead i-1 and for the bead N there is not bead i+1, in the equations of motion of the first bead we consider that every member depending on the hypothetical bead i-1 equals to zero and for the bead N we make the same assumption for every member depending on bead i+1.
Initial conditions As we mentioned, MATLAB ode45 solver needs an initial condition of the state vector. For the straight jet and according to the paper of Vught, initial state vector is defined as: 0 * 0 0 0 0 0 0 0 T hi U N  =   (61) Let us notice that for a straight jet, the curvature of the jet equals to 0. Thus, when we solve the equation in the case of a straight jet, the surface tension force equals to 0. In case of a whipping jet, it means that its x and y coordinated undergo some perturbation. We decided to take as initial vector: T i i h i U Lsin L N  --      =           (62) For this choice we were inspired by Vught's paper where the initial vector for whipping phase is taken as follows 1 33 0 2 2 * 10 0 10 cos 0 0 0 0 20 20 T i i h i U Lsin L N  --      =           (63) General formulas of time and space perturbation have been given in several papers such as: ( )    (Dasri, 2011)  for space perturbation where λ is the wavelength of the perturbation.
15 ). He then observed the impact of initial radius and concluded that the lateral displacement of the beads on the collector was larger when the initial radius is increased (from 200e-4 cm to 500e-4cm). When we tried to implement those parameters in our script with 50 beads the program met a problem of integration. However, Dasri obtained the same results as Vught, which we already verified, concerning the influence of the initial radius on the beads' displacement. The next parameter that was examined was the elastic modulus. The results here show that decreasing the elastic modulus will obtain smaller area on the collector covered by the beads. We may notice that the first paper obtained opposite results. However, the figures in both papers show actually that the difference is slight when increase the modulus up to 100 times.
We implemented the same parameters in our script and obtained approximately the same trajectory when we varied the viscosity (Fig. 18 ). Fig. 18. System of beads, N=20, V=500 V, a0=100e-4cm,μ=10 4 g/cms (left)-μ=10 7 g/cms (right), t=0. 0005s Some literature used dimensionless parameters in order to make the equations dimensionless. In the thesis of Karra we were given the values of α, μ and a0 which allow us to obtain V0,m,G,h,e that we use in our script out of the values of the dimensionless parameters and L. Actually, let's name mLG=k (it appears in every group) and put every known variable on one side and every unknown on the other. We tried to implement the parameters that are given in the thesis of Karra in our model. However, we met some problems of integration and couldn't compare our results.
Conclusions We used the discrete model of Reneker to simulate the trajectory of the electrospun polymer from the needle to the collector. The trajectory and the velocities of the system of beads that formed the polymer in this model were calculated according to the second law of Newton and thanks to Matlab solver ode45. This model allowed us to evaluate the influence of some parameters (viscosity, initial radius, surface tension, elastic modulus…) on the trajectory and the displacement of the beads on the collector. Except some problems of integration, most of our results show good agreement with reports from literature. This will allow us in further studies to determine the optimal parameters to obtain optimal fibers without needing to repeat costly experiences. Further studies will also consist in modifying the script in order to obtain a more realistic jet that goes from straight to whipping jet.
Despite efforts during the past decades, loop modeling remains a difficult part of protein structure modeling. Several approaches have been developed in the framework of crystal structures. However, for homology models, the modeling of loops is still far from being solved. We propose DaReUS-Loop, a data-based approach that identifies loop candidates mining the complete set of experimental structures available in the Protein Data Bank. Candidate filtering relies on local conformation profileprofile comparison, together with physico-chemical scoring. Applied to three different template-based test sets, DaReUS-Loop shows significant increase in the number of high-accuracy loops, and significant enhancement for modeling long loops. A special advantage is that our method proposes a prediction confidence score that correlates well with the expected accuracy of the loops.
Strikingly, over 50% of successful loop models are derived from unrelated proteins, indicating that fragments under similar constraints tend to adopt similar structure, beyond mere homology. Prediction of protein structures is one of the challenging problems in biology 1. This is reflected by the large number of protein sequences known today (about 109 millions) in the Universal Protein Resource (UniProt) 2 versus the number of known protein structures (about 139 thousands) deposited in Protein Data Bank (PDB) 3. Such drastic difference is due to the experimental difficulties of X-ray crystallography or NMR, compared to the rapid rate of new sequences being determined by next-generation sequencing methods. Systematic studies of protein classification demonstrated that existing proteins can be grouped into very few homologous families 4-6.
that concurrently employs the strength of different energy components, considering short-range, hydrophobic and electrostatic interactions. Data-based methods are dependent on the geometry of flanking residues and the database used for mining candidates  40. Flanks are regions before and after the loop to be modeled. For the completion of crystal structures, these methods are shown to generate successful results when similar fragments to the loop of interest exist in the database  41. ArchPRED  42  considers the secondary structures flanking the missing loop, their relative orientation and the number of missing residues to identify candidate loop conformations. FREAD  43  searches for candidate fragments matching conditions on distances between C α of the flanks. LoopIng  37  is based on Random Forest model and considers sequence and geometry related features to select the candidates.
SuperLooper2  44  mines the Loop In Protein (LIP) database  45  , a comprehensive loop database containing all protein segments up to 35 residues from the PDB, to identify fragments matching geometrical criteria between the two last atoms of the main chain of one flank and the two first of the other. Hybrid loop modeling methods combine ab initio and data-based methods to improve the quality of loop predictions. CODA generates a consensus loop prediction using both ab initio and data-based methods independently  40. Similar approaches are considered by others to predict complementary determining region (CDR) of antibodies  46, 47. Another recent method is Sphinx, which first performs data-based search to find fragments shorter than the loop of interest and obtains structural informations  41.
Effects of the filtering. In this section we report the effect of filtering over the set of all loop candidates retrieved from our dataset for CASP11 test set. The distribution of sequence identity (BLOSUM scores) with respect to loop local RMSD are shown in Fig. 2a. 36% of the candidates have positive BLOSUM scores and 62% of them have local RMSDs of less than 4Å. In total, this step makes the fraction of fragments with RMSDs less than 4Å increase from 49% before filtering up to 62%. Figure  2b  depicts the impact of clustering. As expected, it results in a drastic decrease of the number of candidates. It also comes with a slight improvement in terms of the RMSDs. The mean (resp. median) RMSD is of 3. 86 (resp. 3. 60)Å before clustering and of 3. 60 (resp. 3. 24)Å after. As an outcome, 70% of the candidates selected have a RMSD value <4Å.
Prediction confidence index. We now turn to analyzing whether a prediction confidence could be assigned based on the min(JSD) score, which indicates the best fit of any candidate loop in terms of conformational profile. Figure  3  shows a clear trend that lower min(JSD) values are associated with lower RMSDs, with a Spearman correlation of 0. 76. From the figure one also observes a clear jump in the range of RMSD values between min(-JSD) of 0. 20 and 0. 25, and for JSD values more than 0. 20, the quality of the correlation appears degraded. This analysis suggests that min(JSD) can be considered as a measure to assess the overall case-by-case loop modeling quality and to detect failures of our protocol. Therefore, for each of the three datasets, a high-confidence subset was selected (CommonHC), discarding any loop target for which the min(JSD) is more than 0.
The protocol can take 10-40 minutes (using 40 threads of a 2. 2-GHz Intel Xeon processor). The CPU-time needed for DaReUS-Loop is in the range of 10 min to 25 hours, (CPU-time: BCLoopSearch 1-10 min, clustering 1-5 min, local conformation 3 min, local conformation filtering 15 s per candidate and MODELLER 30-50 s per candidate). It has to be stated that in rare cases the number of possible loop candidates might be very large (several hundreds of thousands), consequently this leads to proportional increase in the computational time. Such increase is mostly due to the computations of MODELLER. It has to be mentioned that we pre-computed the local conformation profiles for all the protein chains in our structure dataset, otherwise the computational cost of this step is 3 minutes for every candidate.
Moreover, for the high-confidence subset, long loops (≥15 residues) modeled by DaReUS-Loop tend to be more accurate compared to other methods. Modeling long loops has been an unsolved problem, most existing approaches dealing with loops of at most 12 residues. Our protocol tackles this problem and improves the accuracy of modeling long loops, as long as high-confidence loop candidates are available from the database. For the CASP test sets, we extended the gaps to regions between two secondary structures. Such extension can bring two negative consequences: (i) the loop gets longer (and therefore harder) and (ii) it decreases the chances to find a high-confidence loop candidate. However, the results showed that DaReUS-Loop models long loops with higher accuracy compared to the other methods.