dataesr/scientific-paragraphs-categorization huggingface dataset:
The percent of ion contribution (peak area) of each growth condition to each node is denoted by the size of the node. Nodes are colored according to the sample of origin: exclusive to elicited growth conditions (blue), exclusive to control growth conditions (no elicitor added-in white), and common to both elicited and control conditions (yellow). The link's width is proportional to the spectra similarity value between the two connected nodes. Self-loops (nodes with no connections) were excluded for better visualization. Nodes were further compared to MS/MS databases and annotated. The identified nodes are shown in squares. (b) Network organization by grouping the nodes detected preferentially under a given growth condition. Numbers indicate the total number of nodes in each group (including self-loops).
Compounds derived from bioactive fractions are highlighted in grey (LAMA915), green (LAMA639) and red (B002_754). Representative compounds from the spectra databases used for metabolite identification, sharing spectra similarity to the EPfB [M + H] + consensus spectra, were selected and are represented; 6: tentoxin; 7: mucronine J; 8: nummularine F; 9: cyclic tetrapeptide (PheProPhePro); 10: daphnicyclidin; 11: hyrtiazepine; 12: ulongamide D; and 13: cystodytin C. Numbers in red indicate natural products reported from organisms other than bacteria.
DATA In this study, we make use of MUSE IFU data for 19 nearby galaxies taken as part of the PHANGS-MUSE survey  (Emsellem et al. 2021). Full details of the data reduction and processing are given in that work, and so we give only a short summary here. The data reduction is performed using standard MUSE recipes (e. g. wavelength and flux calibration, cosmic ray rejection, mosaicking) developed by the MUSE consortium and carried out by the MUSE data reduction pipeline  (Weilbacher et al. 2020) , available to the community via the esorex package (ESO CPL Development Team 2015) and accessed using a wrapper pymusepipe 2. These reduced products are then processed through a data analysis pipeline (DAP 3  ), which is run in three stages: firstly, stellar kinematics are measured (the stellar velocity and higher-order moments).
Next, the properties of stellar populations are estimated (e. g. stellar age, mass, and metallicity). Both of these stages are performed on Voronoi binned data to a stellar continuum signal-to-noise ratio (S/N) of 35, to maximise reliability. The fit is performed via  (Cappellari & Emsellem 2004; Cappellari 2017) , and makes use of E-MILES  (Vazdekis et al. 2016 ) single stellar population models of eight ages (0. 03-14 Gyr, logarithmically spaced in steps of 0. 22 dex) and four metallicities ([Z/H] = [-1. 5, -0. 35, 0. 06, 0. 4]). Only the wavelength range 4850-7000 Å is used in the fit (of the full 4750-9350 Å range), in order to avoid strong sky residuals in the reddest part of the MUSE spectral range. Finally, for individual spaxels the properties of emission lines are measured (fluxes and kinematics), via a simultaneous fit of continuum and emission lines also performed via.
The final DAP products are 2D maps of the intensity, velocity, and higher order moments of these emission lines (and associated uncertainties), as well as the properties of the stellar populations. We make use of the DAP products produced as part of the first public data release, and use the 'optimally convolved' (COPT) products. In each case, we show all pixels in the convolved NGC 3627 map as a black cloud, those that satisfy both BPT constraints (i. e. are below both black lines) in yellow, and those that satisfy all our data constraints (S/N > 5, velocity dispersion < 100, within morphologically defined H II region, see Sect. 2. 2. 1; i. e. those that form our final pixel map) in blue. Because each galaxy is observed with multiple MUSE pointings and mosaicked together, there are variations in seeing across the complete mosaic.
Convolution Although the COPT DAP products represent a homogeneous angular resolution across the galaxy (and wavelength range), with the different distances and seeing conditions for the 19 galaxies, this does not represent a homogeneous spatial scale across our sample of galaxies. We therefore convolve each intensity and (intensity-weighted) velocity dispersion map, along with associated error maps, to a fixed spatial resolution. We choose a common spatial resolution of 120 pc (and pixel size of 60 pc), which is advantageous for two reasons: firstly, the native PHANGS-MUSE resolution is 25-70 pc, so we can incude all data at 120 pc resolution. Secondly, at this resolution, a typical H II region will be unresolved  (Hunt & Hirashita 2009; Kreckel et al. 2019; Barnes et al. 2021; Santoro et al.
Data Preparation We calculated a gas-phase metallicity, 12 + log 10 (O/H), using our convolved line maps (we will use this oxygen abundance synonymously with metallicity throughout this work). We do not correct for Milky Way (Galactic) extinction, as this is already performed in the MUSE DAP. We correct fluxes for internal extinction. The internal extinction is calculated via the Balmer decrement, is the theoretically expected ratio of 2. 86 (assuming case B recombination, an electron density of 100 cm -3 , and an electron temperature of 10 4  K;  Osterbrock & Ferland 2006). This value is relatively insensitive to the assumed electron temperature, with variations of a factor of ∼2 causing changes of ∼0. 1 mag in -band extinction. The extinction coefficient at a given wavelenngth  is  () = ()/ ( -).
2019). This choice of  imposes a level of smoothness in the final maps, but we find that experimenting with  = 0. 5 leads to an extremely noisy map, and the kernel length scale is not constrained (indeed, this is noted in sect. 4. 2 of  Rasmussen & Williams 2006). We therefore proceed using the standard  = 1. 5, but note that this choice of smoothness parameter may lead us to miss some variation on very small spatial scales (see especially the structure in the right panel of Fig. 5 ). 𝑘 (𝑟 𝑖 , 𝑟 𝑗 ) = 1 + √ 3𝑑 (𝑟 𝑖 , 𝑟 𝑗 ) 𝜎 𝑙,obs exp - √ 3𝑑 (𝑟 𝑖 , 𝑟 𝑗 ) 𝜎 𝑙,obs. (16 We perform the fitting to the radially subtracted metallicity maps, using the GaussianProcessRegressor in scikit-learn, a package for machine learning. We set prior bounds of [0. 001, 5]  25 on  ,obs (where  25 is the 25 th mag isophotal contour, a measure of the galaxy size; see Tab 1), to allow freedom from extremely granular higher-order metallicity maps (this range includes the resolution of the maps) to extremely smooth distributions.
ACKNOWLEDGEMENTS This work has been carried out as part of the PHANGS collaboration. The authors would like to thank the anonymous reviewer, for comments and suggestions that have improved the quality of this paper. This work has made use of AstroPy (Astropy Collaboration et al. 2013; Price-Whelan et al. 2018), Matplotlib (Hunter 2007),  NumPy  (Harris et al. 2020), SciPy (Virtanen et al. 2020), scikit-learn (Pedregosa et al. 2011), and Seaborn (Waskom et al. 2017). This work is based on observations collected at the  European Southern Observatory  under  ESO  programmes  1100. B-0651 ,  095. C-0473 , and  094. C-0623 ,  094. B-0321 ,  099. B0242 ,  0100. B-0116 ,  098. B-0551  and  097. B-0640. This paper makes use of the following ALMA data, which have been processed as part of the  PHANGS-ALMA CO (  = 2-1 ).
DATA AVAILABILITY The MUSE data used in this paper are presented in  Emsellem et al. (2021). ALMA data are presented in  Leroy et al. (2021) , and available online at https://www. canfar. net/storage/list/ phangs/RELEASES/PHANGS-ALMA/. The code used in this paper, along with metallicity maps (and associated error maps) are available at https://github. com/thomaswilliamsastro/ metallicity_gpr.
Phylogenetics is nowadays at the center of numerous studies in many fields, ranging from comparative genomics to molecular epidemiology. However, phylogenetic analysis workflows are usually complex and difficult to implement, as they are often composed of many small, reccuring, but important data manipulations steps. Among these, we can find file reformatting, sequence renaming, tree re-rooting, tree comparison, bootstrap support computation, etc. These are often performed by custom scripts or by several heterogeneous tools, which may be error prone, uneasy to maintain and produce results that are challenging to reproduce. For all these reasons, the development and reuse of phylogenetic workflows is often a complex task. We identified many operations that are part of most phylogenetic analyses, and implemented them in a toolkit called Gotree/Goalign.
The Gotree/Goalign toolkit implements more than 120 user-friendly commands and an API dedicated to multiple sequence alignment and phylogenetic tree manipulations. It is developed in Go, which makes executables easily installable, integrable in workflow environments, and parallelizable when possible. Moreover, Go is a compiled language, which accelerates computations compared to interpreted languages. This toolkit is freely available on most platforms (Linux, MacOS and Windows) and most architectures (amd64, i386) on GitHub at https://github. com/evolbioinfo/gotree, Bioconda and DockerHub.
INTRODUCTION Increase in computer power and development of bioinformatics methods that handle very large datasets make it possible to perform phylogenetic analyses at an unprecedented scale. For example, it is common to perform phylogenetic studies involving several thousand trees or several thousand taxa (e. g. (  1 ) or (  2 )). Such studies often present and run complex pipelines involving many steps and several tools and scripts, which makes them hard to describe and share. For example, the current COVID-19 pandemics and the diverse SARS-CoV-2 data analysis workflows that flourish demonstrate the need to manipulate sequences, alignments, and phylogenetic trees in an easy and automated way (e. g. https://github. com/roblanf/sarscov2phylo/). Figure  1  displays an example of a phylogenetic workflow inspired from (3) and described in details in the Results section.
The main objective of this workflow is to analyse a phylogenomic dataset to infer a species tree and compare it to a reference tree. It contains 19 steps among which the majority is not constituted by usual computer intensive tasks (e. g. tree inference and multiple sequence alignment), but rather by alignment and tree manipulations such as downloading, renaming, reformating, comparing, rerooting, annotating, etc. These tasks are (i) repetitive (found in many similar workflows), (ii) tedious to implement (many ways to do it) and (iii) error prone, which makes this workflow difficult to implement, describe and reproduce. That is why we think a common framework was needed to help implement such analyses in a concise and reproducible way. Several tools, either in the form of command line or APIs, already exist to manipulate phylogenetic trees and/or alignments.
For example, Newick-utilities (10) is a command line tool dedicated to phylogenetic tree manipulation in newick format. ETE toolkit  (11)  is a Python API for the analysis and visualization of trees. Ape (  12 ) is a package dedicated to the analyses of phylogenetics and evolution in the R language. Buddy Suite (  13 ) is another python framework (command line) to manipulate phylogenetic trees and alignments. BIO++ (  14 ) is a C++ library for the analysis of sequences and trees. Lastly, Phyx (15) is a command line tool written in C++ that performs phylogenetic analyses on trees and sequences. Some of these tools (e. g. ape, ETE toolkit, BIO++) are mainly developer oriented and may be difficult to use for non-programmer phylogenetic analysts who are not familiar with R, python or C++. Others are command line only (e.
g. Newick-utilities), and may be of limited use for developers who want to use part of them in their own programs. They are all implemented either in C, C++, Python or R. To our knowledge, no phylogenetic tree toolkit currently exists, which mix alignment and tree manipulation, in a command line environment and via an API, and proposes a large diversity of commands. In particular, none exists for the Go programming language for which several bioinformatics libraries and tools already exist such as biogo  (16)  and Vcfanno  (17). In this context, we developed Gotree/Goalign, a toolkit dedicated to burdensome and repetitive phylogenetic tasks, which (i) consists of two user-friendly executables, gotree and goalign, integrating state of the art phylogenetic commands and requiring no programming skills to use, (ii) provides a set of chainable commands that are integrable in workflows (e.
g. Nextflow  (18)  or Snakemake  (19) ), (iii) is straightforward to install via static binaries available for most platforms and architectures, and (iv) provides a public API accessible to developers wanting to manipulate phylogenetic trees and multiple sequence alignments in Go. The Gotree/Goalign toolkit is already used in several public workflows such as Grapevine (the phylogenetic pipeline for the COG-UK project https://github. com/COG-UK/grapevine), ARTIC-EBOV (The ARTIC Ebola virus phylogenetic analysis protocol https://github. com/articnetwork/artic-ebov), KOVID-TREES-NF (a Nextflow  (18)  workflow for SARS-CoV-2 phylogenetics https://github. com/MDU-PHL/kovid-trees-nf), bioconvert (a generic bioinformatic file format converter https://github. com/ bioconvert/bioconvert), and in phylogenetic studies  (20) (21) (22) (23) (24) (25) (26).
Implementation of Gotree/Goalign The Gotree/Goalign toolkit is implemented in the Go (https://golang. org/) programming language, and thus takes advantage of (i) being available on major operating systems (Windows, Linux, MacOS), (ii) the richness of the Go standard library and the massive amount of available packages (http, hashmaps, compression, regex, channels, concurrency, gonum, etc. ), (iii) the distributed nature of Go packages, providing phylogenetic packages easily accessible to any developers. It consists of two executables gotree and goalign providing all the commands in the same spirit as git or docker. All the commands are implemented in the Unix mindset, having one atomic command per task, reading data from the standard input and writing results to the standard output when possible.
RESULTS: USE CASE IN PHYLOGENOMICS In this use case, we analyze a phylogenomic dataset inspired from  (3) , in which the authors analyze a set of 1730 genes from primates. They infer the species tree either from individual gene trees using ASTRAL III  (32)  or from gene concatenation using maximum likelihood. Our use case is inspired from the concatenation study, inferring a species tree from available groups of primate orthologous proteins in OrthoDB  (5)  after having mapped the RefSeq identifiers of the 1730 analyzed genes to their OrthoDB counterpart. The workflow is displayed in more detail in Figure  1  (code available at https://github. com/evolbioinfo/gotree usecase and in Supp. Data 1), and consists of the following main Tree inferred from the concatenation of 1315 orthologous proteins in 25 primates using maximum likelihood, with Felsenstein's bootstrap supports of the internal branches.
Visualisation of tree topology with branch supports comes from iTOL (9) after upload by Gotree. Branch colors and clade annotations have been added independently. The red branch is the only one that contradicts the NCBI taxonomy, and blue branches are resolved in the inferred tree, but unresolved in the NCBI taxonomy. The topology is identical to the tree inferred with maximum likelihood from gene concatenation in  (3). steps (details of the tools and options are given in Supplementary Figure  S1 ): (i) mapping RefSeq, HGNC (4) and OrthoDB identifiers ; (ii) retrieving each group of orthologous proteins in OrthoDB if they are present in at least 90% of the 25 primate species (Supp. Data 2) and in a single copy (this results in 1315 orthologous groups, listed in Supp. Data 3); (iii) for each orthologous group, downloading the sequences of all proteins and their associated metadata; (iv) renaming, cleaning and aligning sequences using MAFFT (6); (v) concatenating the alignments of the 1315 orthologous groups (this results in a single alignment of 674 089 amino-acids); (vi) cleaning the alignment using BMGE  (7)  (this keeps 516 999 sites); (vii) inferring the species tree using IQ-TREE (8); (viii) downloading the NCBI taxonomy; (ix) comparing the inferred tree with the NCBI taxonomy and (x) uploading both trees to iTOL  (9).
DISCUSSION We developed the Gotree/Goalign toolkit to simplify the manipulation of phylogenetic trees and alignments, and to facilitate the development of reproducible phylogenetic workflows. Importantly, it is not a wrapper around major tree inference and multiple sequence alignment software, i. e. it does not take care of aligning sequences and inferring trees, but rather takes care of all the other complex, tedious and numerous tree and sequence operations that are necessary in phylogenetic workflows. The Gotree/Goalign toolkit is developed in Go and is easily installable on major operating systems and provides a public API usable in any Go project. It is already used in several projects, and we are confident that Gotree/Goalign will be able to build a community interested in adding new functionnalities.
It is now clearly envisioned that delivery systems are specially targeted for autonomous vehicles  [17] [18] [19]. However, thus far, heavy freight delivery is not completely possible in an urban setting through autonomous vehicles. FURBOT will attempt to achieve this milestone for autonomous freight delivery within an urban environment. The concept of using heavy autonomous vehicles is still under study  [20] , but these concepts are still in the conceptual phase and use mini autonomous vehicles for personal package delivery within urban environments. The idea is to use large vehicles (LV) to deliver and deploy small autonomous vehicles (SAV) for personalized deliveries of freight  [20, 21]. The novelty of FURBOT is that it is not only a freight delivering autonomous vehicle, but it is also equipped with fully functional forklifts, capable of loading and unloading freight autonomously.
It is also necessary to identify an open platform as in  [30]  which can help in bonding the new sensor hardware with the mission computer of the vehicle. This research is thus an attempt to address two main core issues for FURBOT for it to be upgraded from its current state to an autonomous vehicle. The first issue revolves around the correct categorization of the vehicle so it can earn legal status on the road. Second, the vehicle must also be upgraded with hardware and software for it to be a fully autonomous vehicle. For that, we should identify the required sensors and the complete platform where the hardware can be easily incorporated in the software.
Afterwards, requirements in context with the current state of the vehicle are analyzed, keeping in view selected vehicle categories. Hurdles to categorize our vehicle in the shortlisted categories are highlighted and analyzed. Thus, we were finally able to resolve the vehicle categorization issue for licensing and insurance purposes. The second focus of this research is to identify hardware and software changes the vehicle requires in order to upgrade itself from a drive by wire to an autonomous vehicle. The methodology opted for resolution of this issue involved a literature search in the type of sensors required by the vehicle to be upgraded to autonomous vehicle. Similar autonomous vehicles are studied to identify sensor requirements. Study participants involved vehicles with similar shape as FURBOT.
• In the technical domain, mathematical modeling for FURBOT is carried out devising obstacle avoidance techniques/strategies  [32, 33]. Further explanation of this work is given in Section 3. 1. The multi-body model is also created for performance evaluation to analyze extreme cases  [34]. • Identification of shortcomings in terms of sensors required and upgrading needed is carried out. • Identification of issues concerning freight approach and autonomous drive within an urban environment are highlighted. Strategies on how to tackle the respective issues are formalized. Furthermore, the hardware of forklifts is also upgraded  [35]. • Development of a plan for upgrading is carried out where hardware and software requirements for the vehicle are completed.
Future Goals The future/upcoming goals for FURBOT are list below. • Initialize the upgrading process, including software upgrading of the vehicle • Incorporate relevant sensors for autonomous driving and autonomous handling of freight, including relevant sensors for identification of freight • Strategies for freight approach and cargo loading are being visualized and simulations are to be developed for the collection of freight, navigation to the drop-off location and drop-off of freight The way forward towards these goals are further discussed in Section 6.
5. Industrial computer (for processing of sensor data) 6. LTE/5G modem (for data communication between vehicle and remote user) 7. GNSS for localization 8. IMU for orientation sensing 9. Medium-range RFID readers (for freight recognition) It is expected to upgrade the vehicle software and hardware architecture for its complete autonomy. 6. 1. Resolution of 3D LiDAR Purchase/Placement/Quantity Issues 3D LiDAR is one of the most expensive sensors that is being purchased for the vehicle. As the vehicle is unconventional compared to typical Apollo Auto vehicle  [40] , typical Apollo Auto conventions cannot be followed. For considerations, three 3D LiDARs have been shortlisted keeping in mind the cost, availability and compatibility with Apollo software  [42] [43] [44]. The specifications which are affecting the decision of the LiDAR are mentioned in Table  7.
Software Requirements Many software architectures are available for autonomous vehicles to interface the hardware with the software. Some software architectures available for engineers are given in  [48]. Under the current software architecture developments, autonomous vehicle software architectures are under constant scrutiny from a security perspective  [49]  and few security concerns are repeatedly highlighted  [50, 51]. Choosing the right software architecture can be an arduous task for an autonomous vehicle designer. The considerations for our team before selecting the software architecture for FURBOT were that the software should be: • Open sourced • Easily accessible • Modifiable • Have a proven track record in the industry Considering the above requirements, Apollo Auto fulfills our requirements, and it is considered as the "Android for autonomous vehicles"  [52].
It has intelligent components such as perception, simulation, planning and intelligent control  [52]. These features help in developing the interface with vehicle's hardware and thus achieving autonomous navigation. Since FURBOT is a freight vehicle and the autonomous freight handling part has to be developed, it is imperative that the selection of our software architecture is programmable and open sourced so that changes in the software could be easily implementable. Considering factors highlighted above, it is thus decided to interface the entire vehicle through Apollo Auto for autonomous and remote controlling for the vehicle. Moreover, the vehicle needs to have a remote control for the vehicle besides on-board autonomous control. The latest launch of Apollo is Apollo 5. 0. Apollo 5. 0 ushers in a brand-new data pipeline service with per-vehicle calibration options, along with spruced-up prediction evaluators and map data verification tools  [53].