dataesr/scientific-paragraphs-categorization huggingface dataset:
We made a wide choice with threading approaches: Phyre2  [64] , de novo, i. e. , I-TASSER  [61] , and Robetta  [62] , and Deep Learning AlphaFold2  [63] , locally, and also with CollabFold (on a reduced basis, as in  [88] ). The confidence indices remain very low for the disordered part of CALRwt (similar to class E) but also for classes A, B, and C. We have to remember that the new sequences obtained via the frameshifts do not exist in nature, and are not, therefore, in the databases, i. e. , the multiple sequence alignments are completely empty and cannot provide any information. Therefore, we kept our models (see Data S1). From a dynamic point of view, it is interesting to see that in the ER, the Ca 2+ ions allow CALRwt and the two CALR classes D and E to strongly rigidify them. The number of possible Ca 2+ binding sites is impressive and made such that depending on the simulation, they could be different.
g. ,  [29]. The last decade has seen several developments on algorithmic graph theory for analyzing various types of molecular dynamics simulations, from e. g. , the conformational analysis of gas phase molecules and clusters, to their chemical reactivity, to the dynamics of H-Bonds in liquids, to the dynamics of the solvation shells of ions in liquids, to the structural and dynamical analysis of complex aqueous interfaces in condensed matter; see for instance  [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41]. Our group has been involved in the development of graph-theory-based methods for analyzing (post-processing) atomistic molecular dynamics simulations (obtained from DFT-based MD and classical FF-MD). These developments are included in the GaTewAY post-processing software described in  [42].
GaTewAY Post-Processing Tool for Time-Dependent Conformational Analysis We have developed 2D molecular graphs (labeled 2D-MolGraph) and associated algorithms in order to automatically analyze the conformational dynamics of molecules and their assemblies from molecular dynamics simulations. The 2D-MolGraph and the algorithms are described in the next section. Different applications are presented in order to illustrate the versatility and transferability of the 2D-MolGraphs that can be applied to gas phase molecules, clusters, liquids, solids and inhomogeneous interfaces between solids and liquids. Our developments are included in the GaTewAY (Graph Theory for conformAtional dYnamics analysis) software described in  [42]. A key component in the versatility and transferability of our 2D-MolGraphs is the atomic level of granularity that was chosen to define the vertices and edges of topological 2D graphs.
This is described in Section 2. 2. Given an MD trajectory, the GaTewAY software thus provides the list of conformations that have been explored based on the isomorphism test from  [43] , their residence time and the "graph of transitions" that represents all transitions that have been observed between the identified conformations along the MD time-length. Examples of applications to gas phase molecules and to more complex inhomogeneous aqueous interfaces will be given in Section 2. 3. GaTewAY can be applied to any kind of MD trajectory, be it ab initio MD, classical MD or coarse-grained MD, or any type of mixing between these atomistic representations, including chemical reactivity. The algorithms are implemented in such a way that they can be easily extended to take into account any other types of interactions and parameters to analyze the conformational dynamics.
• Construction of the series of 2D MolGraphs: This stage consists in constructing the series of 2D MolGraphs from the list of the positions of the atoms given by the trajectory file(s). At each step (snapshot) I of the MD trajectory, the list of atoms and their cartesian coordinates are known. Depending on the chemical type, we have established a database in which each possible atom has a specific covalent radius and a maximum number of covalent bonds that it can form. For each type of bond/interaction, a set of threshold distance/angle values have been established. These values are in a database that can be easily modified by any user. We always choose the nearest atoms to fix the eventual bond overflow, especially when the user sets high cut-off values. For example, given an atom a that should form at most one covalent bond, and two atoms b and c that respect the condition to form a covalent bond with atom a, whenever the distance(a, b) is less than distance(a, c), the algorithm will choose atom b for establishing a covalent bond from atom a as atom b has the shortest distance from atom a.
Evaluation and Validation The GaTewAY software can analyze any molecular dynamics trajectory, i. e. , AIMD, QM-MM-MD, FF-MD, CG-MD. Because of the atomic granularity level chosen for the 2D-MolGraph definitions, GaTewAY is versatile and can be applied to trajectories of gas phase molecules and clusters, to solids, nano-particles, to any complex inhomogeneous molecular system as e. g. , solid-water interfaces. In the following, we illustrate applications of the 2D-MolGraphs and associated graph algorithms in the gas phase (analysis of the trajectory of an isolated protonated peptide Z -Ala 6 -COOH, C 26 H 39 N 7 O 8 ) and in the condensed phase for trajectories of hydrophobic surfaces in contact with liquid water (air/water, graphene/water, boron-nitrate BN/water).
Methods for generating the 3D structures of conformers have been developed in the literature. See for instance  [50] [51] [52] [53] [54] [55] [56]. Some of these methods typically rely on databases of 3D structures of sub-units that will be used to generate a reasonable conformation of a more complex molecule. Other methods rely on crystallographic databases for the initial construction. Nowadays, topological databases based on 2D graphs such as the ones presented in the first part of this paper are becoming more in use. See for instance the topology-based databases of  [18, 57]. Furthermore, the 3D prediction of e. g. , proteins typically takes advantage of the large amount of available 3D data and the specificity of local structures in these biomolecules  [58]  to propose prediction approaches by Deep Learning (see e.
g. ,  [59] ), which turns out to be interesting alternatives to energy minimization approaches for these particular molecules. In our specific context, the present development is part of this latter domain, i. e. , to generate 3D structures of molecular conformers from a database of 2D graphs. In our case, the database is built on the 2D-MolGraphs that were presented in Section 2 of this paper. We show in this section of the paper the algorithmic methods that we have developed based on game theory and reinforcement learning in order to generate the 3D structure of a gas phase molecule from the sole knowledge of its 2D-MolGraph. We stick to isolated molecules in the present presentation and application. The methodology should be transferable to the more complex domain of the condensed phase.
Ongoing works in our group aim at applying the 2D-MolGraphs to biomolecules such as proteins. The 2D-MolGraphs and their associated canonical graphs are fast to compute. For instance, on a simple desktop machine (Macbook Pro, i7, 8Go RAM), it takes 0. 9 s for one snapshot of BPTI (Bovine Pancreatic Trypsin Inhibitor, 1QLQ, 896 atoms) and 146 s for one snapshot of GLP-1 (Human Glucagon-like Peptide-1 Receptor, 7S15, 6458 atoms). This opens the route to rapid analyses of the trajectories of biomolecules with the 2D-MolGraphs. The GaTewAY software  [42]  has been developed and includes the definitions of the 2D-MolGraphs presented in this paper, as well as the graph algorithms applied in this paper. As discussed in the text, this software is easily modified and can be expanded in order to include supplementary definitions for the edges of the 2D-MolGraphs.
Scenario and involved stakeholders The high-level scenario considered in this work is depicted in Figure  1. We envision two main stakeholders: • Application provider: it develops microservice-oriented application, used by its customer(s) to execute some specific tasks. A reference example to this respect may be an application monitoring the vehicular access to a restricted traffic area. The customer, e. g. , a municipality, needs an application to perform the following chain of tasks: access a camera covering the said area (task 1), capture plates' number images for the vehicles entering the area (task 2), convert the plate number image into a plate number text (task 3), store the plate number into a database (task 4) and match it with authorized plate numbers (task 5). An application of this kind suits well the microservice-oriented architecture since each of the above tasks can run on a different microservice module.
Each module is mapped to a host of the infrastructure, and link mapping is performed together with node mapping. Figure  3a ) shows a high-level view on how basic DFS and BFS approaches work  [1]. Both rely on a topological sorting of applications' graphs, and they differ on how the node mapping is performed through the different iterations. Figure  3b ) shows instead how iBFS works. The main differences with BFS rely on both initial applications partitioning and on applications' modules deployment. In iBFS each application is partitioned with respect to locality constraints and all the sets of the partition are sorted according to the indexes of the regions towards which the locality constraints are defined. A last set of the partition includes all the modules of the application that have not locality constraints.
For simplicity, Fig. 3b ) shows a case where any module of any application is subject to a locality constraint. On the nodes mapping side, unlike the previous BFS version, iBFS can deploy more than one module, for each application, in each iteration. Indeed, the new algorithm deploys all the virtual nodes belonging to the set on top of the application's stack obtained by the initial partitioning procedure, which all have a locality constraint set towards the same region. More in detail, the virtual node mapping (step 3) selects a set of admissible regions accounting for the requirements and the locality constraints of each application's module. If a locality constraint exists for a module, only one region is admissible. Once the set is defined, the algorithm greedily selects the regions leading to the lowest deployment cost.
Algorithm description and pseudocode The pseudocode of the algorithm is reported in Algorithm 1. iBFS Deployment first sorts all the applications by their total bandwidth requirement computed as the sum of the throughput requirements on each applications' virtual link (line 2). Afterwards, for each application A in the defined order, the algorithm performs a region-based sorting. First, it partitions A according to the locality constraints defined on the modules. Each set of the partition is associated to a specific region u ∈ V I. In this manner, the set associated to region u contains all the application's modules that have a locality constraint specified on region u. The cardinality of such a partition is |V I | + 1, i. e. , the total number of regions plus the set of all modules without locality constraints.
In the first one we compare iBFS with the other strategies, including the BFS approach proposed in  [1] ; for the sake of comparison, we consider the scenario reported in the same paper, i. e. , when only one locality constraint is specified for the first module of each application, which must be mandatorily placed in the main domain. The scenario is called here Original Case. In the second case each module of each application is subject to a locality constraint with assigned probability p. We call this Random Case. In this case, we highlight the shortcomings of BFS that are solved by iBFS. The last case specifies two locality constraints for each application. The first constraint requires that the first module of each application is deployed on a specific domain external to the main one. The second constraint requires that the last module of each application must be deployed on the main domain.
Tools The most common fog simulators in the literature  [35]  do not offer support for scenarios with multiple domains and fog regions yet. Hence, for the evaluation of the proposed algorithms, we developed a Python-based simulator from scratch. For the resolution of the optimal placement ILP problem (OPT) we used the Gurobi solver  [36]. Each data point in the reported graphs is the obtained average value over 30 randomized instances, where the network infrastructure does not change while the batch of applications and host distribution are randomly generated as described above. All the points are reported with their corresponding 95% confidence interval. The optimisation problem is solved from the main fog provider's perspective. Her domain consists of one cloud and one fog region while the other regions are distributed among the remaining external providers.
Original Case Figure  4  evaluates the optimality-feasibility tradeoff of the different solutions in a scenario with V I = 3. In this case we imposed the constraint where the first module of each application must be deployed on main domain's fog region. Fig-  ures 4a ) and 4b) report on feasibility and optimality of the proposed solution, namely iBFS, against two variants of the stateof-the-art DFS approach and the initial BFS approach presented in  [1] , namely BFS. DFS_SoA_NoCost does not take into account the deployment cost optimization, hence, its objective is just the maximisation of the number of deployed applications. Conversely, the objective of DFS_SoA_Cost is the minimisation of the deployment cost, as defined in  (1). From Figure  4a ) it can be noticed the high feasibility of OPT, iBFS, BFS and DFS_SoA_NoCost for all the sizes of the application's batch.
Indeed, these approaches can deploy the complete batch of applications in all the randomised instances, reaching a feasibility of 100%. With the term feasibility we indicate the percentage of feasible instances among all the generated ones. Furthermore, from Figure  4b ) we can notice the closeness of BFS and iBFS to the optimal solution (OPT). On the other hand, although a good feasibility percentage, DFS_SoA_NoCost presents a high deployment cost. Conversely, DFS_SoA_Cost presents a low deployment cost, but its feasibility percentage drops dramatically with respect to DFS_SoA_NoCost. This is reasonable as the DFS approach is greedy by its inherent nature. Indeed, by combining DFS with cost minimization for resources allocation, the regions in the main domain with lowest cost are prioritized to host the applications' modules.
In this way, lower cost resources are saturated soon, thus precluding the possibility to satisfy the locality constraints for the applications that have not been deployed yet. The same rationale explains the higher performance figures obtained with a BFS microservice placement: instead of performing the full placement of an application at each step -with all its microservices, both BFS and iBFS consider the deployment of a few modules of each application at each iteration. Thus feasibility percent- ages improve, since this helps to meet locality constraints, and yet it leads to a consistent reduction of the deployment cost. To summarize, Figure  4  confirms that BFS-based solutions can guarantee a better trade-off between optimality and feasibility if compared to both DFS variants. In Figure  5a ) we evaluate the bandwidth consumed by the proposed solutions inside and outside the main domain.
This is due to the different initial sorting of application modules with respect to iBFS. Indeed, the BFS approach does not prioritize locality, i. e. , it deploys microservices based on the initial topological sorting of applications. This can lead to an early saturation of a certain region preventing that other locality constraints of other applications and on the same region are met. Conversely the iBFS approach, with its initial region-based sorting and partitioning, ensures that all the locality constraints are met. After showing that iBFS outperform BFS, from now on we only focus on iBFS and further evaluate the impact of locality constraints on the applications' deployment. We compare iBFS with OPT and DFS_SoA while varying the probability p ∈ {0. 2, 0. 5, 0. 8} and q = 0. 5. Figure  7   ent infrastructure sizes: |V I | = 3 for Figure  7a ), and |V I | = 6 for Figure  7b ).
Realistic Case To simulate a more realistic case, we evaluated our approach imposing locality constraints only on the first and the last module of each application. For the first module, the locality constraint is set on a randomly-selected fog region external to the main domain. For the last module, the locality constraint is imposed on the fog region of the main domain. Indeed, this simulates the situation where an application needs for an external device, like a sensor or a specific camera, located in an external domain, and the final results of the computing process need to be stored locally in the main domain (e. g. to guarantee privacy). Figure  9  confirms, even in this case, the similar behaviour of iBFS and the optimal solution in terms of feasibility, average deployment cost, bandwidth and CPU utilisation.
⋆ This work has received funding from the  EU   H2020 R&I Programme  under Grant Agreement no. 815141  ( DECENTER ) and  EU   Horizon Europe R&I Programme  under Grant Agreement no. 101070473  (FLUIDOS). The work of  F. De Pellegrini  has been partially supported by the  French National Research Agency (ANR)  within the framework of the  PARFAIT project  ( ANR-21-CE25-0013 ). A preliminary version of this paper has been presented at COINS 2020 [1].
Statistics and recommendations to complement MDAR. Describe statistical tests used and justify choice of checklist (eg. , CONSORT, PRISMA, ARRIVE) is tests. ARRIVE) have been followed, and whether a State if relevant guidelines (eg. , ICMJE, MIBBI, Yes (indicate where provided: page no/section/legend) Yes (indicate where provided: page no/section/legend) Not detected. Not detected. Not currently checked by SciScore n/a n/a Experimental study design (statistics details) provided with the manuscript. Yes (indicate where provided: page no/section/legend) n/a State whether and how the following have been done, Data availability Yes (indicate where provided: page no/section/legend) n/a or if they were not carried out State whether newly created datasets are available, Not detected. Sample size determination Randomization including protocols for access or restriction on access.
If data are publicly available, provide accession ACMI-D-23-00162. pdf not detected. The complete datasets are available online at 10. 6084/ not detected. Blinding If publicly available data are reused, provide accession Not detected. not detected. number in repository or DOI or URL. m9. figshare. 24051063. By Abdourahamane Yacouba inclusion/exclusion criteria number in repository or DOI or URL, where possible. not detected. Not currently checked by SciScore Provide species, sex and age where possible Sample definition and in-laboratory replication Code availability Yes (indicate where provided: page no/section/legend) Yes (indicate where provided: page no/section/legend) n/a n/a Model organisms: Provide Accession number in State number of times the experiment was replicated For all newly generated code and software essential repository (where relevant) OR RRID in laboratory for replicating the main findings of the study: See laboratory animals section for information.
Not detected. Define whether data describe technical or biological State whether the code or software is available. Not detected. The complete datasets are available online at 10. 6084/ replicates m9. figshare. 24051063. If code is publicly available, provide accession Not detected. Ethics number in repository, or DOI or URL. Yes (indicate where provided: page no/section/legend) n/a Studies involving human participants: State details of Ethical approvalAll procedures were approved by the authority granting ethics approval (IRB or equivalent Research Ethics Committee of Amirou Boubacar Diallo committee(s), provide reference number for approval. National Hospital (HNABD/2022/014, approved on 11 January 2022). Studies involving experimental animals: State Ethical considerationEthical approval was obtained from the details of authority granting ethics approval (IRB or Ethical Review Committee of the Hôpital National Amirou equivalent committee(s), provide reference number for Boubacar Diallo, Niamey, Niger.
approval. Studies involving specimen and field samples: State if Not detected. relevant permits obtained, provide details of authority approving study; if none were required, explain why. Dual Use Research of Concern (DURC) Yes (indicate where provided: page no/section/legend) n/a If study is subject to dual use research of concern, Not currently checked by SciScore state the authority granting approval and reference number for the regulatory approval WORD COUNT 4333 TIME SUBMITTED 30-AUG-2023 10:00AM PAPER ID 102366305 Plants and microbes Yes (indicate where provided: page no/section/legend) n/a Plants: provide species and strain, unique accession number if available, and source (including location for collected wild specimens) Not currently checked by SciScore Microbes: provide species and strain, unique accession number if available, and source Not currently checked by SciScore Human research participants Yes (indicate where provided: page no/section/legend) n/a Identify authority granting ethics approval (IRB or equivalent committee(s), provide reference number for approval.
Purpose: X-linked hypophosphatemia (XLH) is a rare, chronic, genetic condition characterized by renal phosphate wasting and abnormal bone and teeth mineralization. It represents a challenging and multifaceted disease that causes wide-ranging impacts on patients' lives. In this context, a scientific committee has designed a support initiative for patients treated for XLH: the aXess program. We sought to determine if a patient support program (PSP) could help XLH patients cope with their condition. Methods: During the 12 months of participation in the aXess program, XLH patients were contacted by phone by a nurse to coordinate their treatment, ensure treatment adherence, and provide motivational interviews. A Pediatric QOL inventory was conducted on all participants at enrollment (D0), at month 6, and month 12.
[10] [11] [12] [13]  Patientys' aXess program is a patient support program for patients with XLH and their families. The aXess program supports patients and families during periods of stress and uncertainty. Preserving patient adherence to prescription schedules is critical to any effective treatment regimen. The service was provided by trained and certified nurses. Through training, nurses achieve a thorough understanding of the XLH pathophysiology. This critical program component serves as a trusted intermediary between patients and caregivers. In addition, trained nurses work with patients to ensure they adhere to their prescription therapy by coordinating injection schedules. The overarching purpose of the aXess program is to help patients better manage their disease and complex prescription regimens, increase treatment adherence, and reduce anxiety to enhance their overall quality of life.