dataesr/scientific-paragraphs-categorization huggingface dataset:
Based in part on observations at  Cerro Tololo Inter-American Observatory, National Optical Astronomy Observatory , which is operated by the  Association of Universities for Research in Astronomy (AURA)  under a cooperative agreement with the  National Science Foundation. The National Radio Astronomy Observatory is a facility of the National Science Foundation operated under cooperative agreement by  Associated Universities, Inc. This research has made use of NASAʼs Astrophysics Data System and the  NASA/IPAC  Extragalactic Database (NED), which is operated by the  Jet Propulsion Laboratory, California Institute of Technology , under contract with the  National Aeronautics and Space Administration. This work made use of the KUBEVIZ software, which is publicly available at http://www. mpe. mpg.
Introduction Some of the central questions in high-mass star formation research relate to the fragmentation and disk formation processes as well as the physical and chemical conditions during the formation of massive stars. To address these questions, we conducted the IRAM large program CORE "Fragmentation and disk formation in high-mass star formation" combining observations with the Northern Extended Millimeter Array (NOEMA) and the IRAM 30 m telescope. An introduction to the survey, its scope and initial results focusing on the 1. 3 mm continuum emission can be found in  [1]. In addition to the original CORE program targeting 20 high-mass protostellar objects, we extended the survey to earlier evolutionary stages via the CORE-extension project that targets two younger regions at the onset of high-mass star formation  [2, 3].
Dynamical cloud and star formation Within the CORE-extension program, we targeted two younger regions in larger-scale mosaic observations. In addition to similar analysis as outlined above, these data also allow us to investigate the cloud formation processes. Figure  5  shows the DCO + 1st moment map and a position-velocity cut through the ISOSS23053 region. Interestingly, we find two wellseparated velocity components that meet exactly at the location where most of the dense cores are identified in the 1. 3 mm continuum emission. At core positions we measure velocity gradients as large as 50 km s -1 pc -1. These are clear signatures of converging gas flows that appear to be conducive to trigger star formation at their interaction zone. More details can be found in  [2, 3].
Summary and outlook As outlined so far, the IRAM CORE program allowed us to derive exciting results for a broad range of physical and chemical questions in the field of star formation. Nevertheless, open questions remain. For example, the spectral setup in the 1 mm band did not cover many important ground-state lines, also from deuterated species. We therefore started a CORE+ study at NOEMA  (Gieser et al. ) , targeting the CORE regions in the 3 mm band. Furthermore, while 20+ regions in the CORE and CORE-extension studies are already a big leap compared to earlier studies, larger statistical studies are now possible. For example the ALMA large program ALMAGAL targets more than 1000 regions in various evolutionary stages in a similar spectral setup. These data will allow us to address many of the here discussed topics on statistical grounds.
With this design, Fisher matrix analyses forecast that EWS 3 × 2pt datasets will obtain a DE FoM of 500 for a non-flat w 0 -w a CDM model in an optimistic setting (defined by the range of scales used; see Euclid Collaboration:  Blanchard et al. 2020). It is interesting to compare Euclid 3 × 2pt forecasts with the constraints obtained by DES, which can be considered as representative of ongoing Stage III surveys. DES Year 1 constraints for a w 0 -w a CDM model  (Abbott et al. 2019 ) are intermediate results, where the uncertainties obtained for w 0 and w a are a factor of 10 larger than the Euclid forecasts in the pessimistic setting (roughly translating to a factor of 100 in the FoM). The DES DE FoM from the DES Year 3 analysis of a more complete dataset is not yet available, but we can use instead the results on S 8 = σ 8 (Ω m/0.
3 ) 1/2 to compare Stage-III constraints with Stage-IV Euclid forecasts. Using a 3 × 2pt dataset and marginalizing over 25 nuisance parameters and 7 cosmological parameters of a flat wCDM model, DES Year 3 gets 3. 2% errors on S 8 (DES Collaboration Fig. 1 : The Euclid timeline. The EWS has to be carried out within the six year mission baseline and will start 3 months after the launch, following a commissioning (1 month) and a Performance Verification period  (2 months ). An extension of operations beyond the six years is possible and will be decided in due time. A faster replanning is allowed during the Early Operation Phase of six months. The three main Data Releases (DR#) are shown. The plan is to have 2500 deg 2 made public in DR1, to grow to 7500 in DR2 and be complete at DR3 for 15 000 deg 2.
Photometry Photometry will be measured for objects down to a minimum of m AB = 24. 0 mag for 5 σ point-like source in the Y, J and H passbands. The photometric data support the GC experiment by providing the reference images needed to extract the spectra in the (slitless) dispersed images. The NIR photometric data, however, critically complement the ground-based observations (Sect. 5. 5) in getting accurate photometric redshift estimates, at the primary probe level mainly needed for the WL experiment and essential for many other astronomical science aspects.
These levels were first introduced in  Laureijs et al. (2011)  and later on fine tuned to optimally match the spectral energy distribution of the z=1 m VIS =24. 5 galaxy populations anchored on the Y, J, H depths of 24. 0 that will be achieved by Euclid. At the time of the mission selection in 2012,  Laureijs et al. (2011)  commented on ground surveys that were still speculative: only the Dark Energy Survey (DES, Dark Energy Survey Collab- When on the sky, Rubin will be the most powerful widefield imager ever built and the Euclid minimal depths in the ugriz bands will be reached within one year of normal Rubin LSST operations over the 8000 deg 2 overlapping the Euclid RoI in the southern sky; this will supersede the DES dataset. The Rubin Observatory being such a powerful machine, the Euclid Consortium is investigating with the Rubin community a northern survey extension serving various strategic Rubin scientific niches  (Rhodes et al.
g. transmission) and off-sky calibrations (e. g. flat fields). The latter have the least constraints as they can be executed independently of the spacecraft's pointing; the scheduling must merely respect the required cadence within some tolerance. On-sky calibrations have the additional constraint that they must minimally disturb the thermal equilibrium of the spacecraft. To this end, a selection of targets is available, from which we choose those that optimally merge with the scientific observations. In the following we provide a summary of the main aspects of the calibrations that impact the building of the EWS (excluding the additional calibration data taken during the performance verification phase, and shorter instrumental calibrations that are integrated in the ROS; see Sect. 4. 1).
This condition is met after about one week without large changes in the SAA and AA attitude angles, i. e. as close as possible to the values used in the preceding days of EWS observations. The VIS PSF calibration data hence need to be embedded in the currently executed EWS patch. In the global schedule (Fig. 29 ), the longitudes of the PSF calibration fields are marked on the top row, and the related observations are shown by the red strips within the EWS observation blocks.
When scheduling the targets we need to make sure to leave enough time for EWS in each year, in order to fulfil the planned public delivery of reduced data to the community (Sect. 1). We note that for the reasons explained in Sect. 7. 4. 2, the polar caps at high ecliptic latitudes (|β| ≥ 79°) are also part of the stage-1 schedule. Each of the two polar caps is covered with a fixed number of patches (thirteen in the northern polar cap, six in the southern polar cap), defining targets that are scheduled with a locally fixed patch area and sequence, i. e. these two regions of the EWS are observed with the same strategy as the EDFs and EAFs. The resulting schedule is called the 'stage-1 schedule', and its computation consists of three steps: 1. analysis of each target (strategy and visibility); 2.
In order to decrease the number of interruptions to the EWS observations and the number of large slews used, these observations are always scheduled in sequence and executed at the same sky field, defining a 'recurring calibration block' Finally, every four weeks starting on Mondays at noon (UTC) ± 1. 2 h, there is one block of 12 h that is reserved for spacecraft orbit maintenance operations (SOP). During SOP time survey data cannot be taken.
The Euclid reference survey definition In this section we present the latest version of the "Euclid reference survey definition" (RSD), RSD_2021A. This is the result of the stage-1 and stage-2 scheduling procedures (cf Sects. 6. 3 and 7), and the corresponding ECTile outputs are the ones shown in Figs. 29  and 45. We recall that the RSD observations start three months after launch. They are preceded by a one-month commissioning phase, followed by a two-month performance verification (PV) phase. During the PV phase the first survey-like data will be obtained, which are used to verify the data processing, and to vali-date and eventually tune or adjust the nominal sequence of operations (possible minor changes to the RSD can be implemented in less than one week time, producing a new version of the RSD; more complex changes of course require more time).
Acknowledgements. The Euclid Consortium acknowledges the  European Space Agency  and a number of agencies and institutes that have supported the development of Euclid, in particular the  Academy of Finland , the  Agenzia Spaziale Italiana , the  Belgian Science Policy , the  Canadian Euclid Consortium , the  Centre National d'Etudes Spatiales , the  Deutsches Zentrum für Luft-und Raumfahrt , the  Danish Space Research Institute , the  Fundação para a Ciência e a Tecnologia , the  Ministerio de Economia y Competitividad , the  National Aeronautics and Space Administration , the  National Astronomical Observatory of Japan , the  Netherlandse Onderzoekschool Voor Astronomie , the  Norwegian Space Agency , the  Romanian Space Agency , the  State Secretariat for Education, Research and Innovation (SERI)  at the  Swiss Space Office (SSO) , and the  United Kingdom Space Agency.
Tis technique presents several disadvantages, such as the traumatic and ionizing nature of the X-rays and the high cost of imaging equipment. Moreover, depending on the age of the patient, the density of tissues, and the efciency of the radiologist, it can sometimes lead to a high rate of false results  [2]. Currently, there are ongoing works aimed at optimizing the results of this breast imaging modality based on new optimization algorithms, such as multiobjective and electromagnetism-like (EML) proposed by researchers Ittannavar and Havaldar  [3]  and Pezeshki  [4]  for the segmentation of tumors with high resolution and precision from mammographic images collected by dedicated databases. (ii) Magnetic resonance imaging (MRI): this system is based on the excitation of hydrogen protons by a strong electromagnetic feld.
(ii) Considering the lower part of the muscle layer is assumed to be at a core body temperature such as T � T c � 37 °C. (3) (iii) At the skin surface, the thermal boundary condition was expressed as -k zT zη � h f T s -T f 􏼐 􏼑, (4) where h f represent the heat convection coefcient between the surrounding air and the skin surface. T f is the temperature of the surrounding air, T s is the surface temperature of skin. Nevertheless, for reasons of efciency and saving time, we have preferred to use the COMSOL multiphysics software to solve these equations. Te simulations carried out by this software, as depicted in Figure  2 , show that a 1 cm diameter tumor located 2. 5 cm deep, can create a gradient on the surface that is signifcantly higher than the sensitivity of the proposed bioheat microsensors and, therefore, can be easily detected  [18].
Results of Experimental Testing of the Prototype Figure  12  shows how we adapted the prototype of the wearable system of thermography to the breast phantom. Te 28 miniature bioheat sensors are positioned to cover the most vulnerable zones of the breast. Similarly, we assigned a reference to each bioheat microsensor in order to identify it on the wearable system of thermography, as well as its corresponding point on the surface of the right breast phantom. Let us specify that the choice of the distance of 1. 5 cm between bioheat microsensors was based on a research using COMSOL multiphysics software. Indeed, according to the simulations carried out, the minimum distance between 2 points so that their thermal gradient is greater than the maximum sensitivity of the bioheat microsensor is 1. 5 cm, i.
Conclusions and Prospects for Future Research Trough this work, we have demonstrated the medical feasibility of a wearable system of thermography for the early breast cancer detection by deploying a hand-held, precise, and noninvasive thermographic system. Te efectiveness of this system has been proven, frst by several simulations using the COMSOL multiphysics software, which demonstrated the existence of thermal gradients on the surface created by tumors placed in diferent quadrants and at diferent depths. Ten, the experimental tests carried out on breast phantom. As perspectives, our future work aims to evaluate and validate clinically this wearable system of thermography by working on target and witness populations proposed by our oncologist partners in Rabat and Casablanca. Furthermore, other confgurations of bioheat microsensors are under investigation, as well as the development of an artifcial intelligence to explore in real time the gradients measured and to extract a useful diagnosis for the attending doctor and the patient, Indeed, our thermal system allows to map breast images based on a network of microsensors representing the pixels of the thermal image and using a radiomics-guided by deep learning algorithms approach which is integrated into electronic chip of the thermal system to predict the malignancy degree of early stage of breast cancer.
Acknowledgments Tis research project was selected for funding under the  AL-KHAWARIZMI program , through a call for applied research projects in the  feld of Artifcial Intelligence (AI)  and its applications under the subsidy of the  Ministry of Industry, Trade and Green and Digital Economy (MITGDE)  in partnership with the  Digital Development Agency (DDA)  and the  National Center for Scientifc and Technical Research (CNRST).
Introduction CompCert  [32, 33, 34]  is a formally verified compiler for a large subset of the C99 language (extended with some C11 features): there is a proof, checked by a proof assistant, that if the compiler succeeded in compiling a C program and that program executes with no undefined behavior, then the assembly code produced executes correctly with the same observable behavior. Yet, this impressive claim comes with some caveats; in fact, there have been bugs in CompCert, some of which could result in incorrect code being produced without warning  [57]. How is this possible? The question of the Trusted Computing Base (TCB) of CompCert has been alluded to in general overviews of CompCert  [35, 25] , but there has been so far no detailed technical discussion of that topic. While our discussion will focus on CompCert and Coq, we expect that much of the general ideas and insights will apply to similar projects and other proof assistants: other verified compilers, verified static analysis tools, verified solvers, etc.
We analyze the TCB of the official releases of CompCert, 1 and two forks: CompCert-KVX, 2 adding various optimizations and a backend for the Kalray KVX VLIW (very large instruction word) core, and CompCert-SSA, 3 adding optimizations based on single static assignment (SSA) form  [2, 14]. Versions and changes to these software packages are referred to by git commit hashes. We discuss alternate solutions, some of which already implemented in other projects, their applicability to CompCert, as well as related work. Sections 2 and 3 analyze the TCB part coming from Coq usage. Section 4 presents the TCB part connecting the Coq specification of CompCert's inputs (source code) to the user view of these inputs. Sections 5 and 6 analyze the TCB part connecting the Coq specification of CompCert's generated programs to the actual platform running these programs.
The Coq Proof Assistant CompCert is mostly implemented in Coq,  4  an interactive proof assistant  [52]. Coq is based on a strict functional programming language, Gallina, based on the Calculus of Inductive Constructions, a higher-order λ-calculus. This language allows writing executable programs, theorem statements about these programs, and proofs of these theorems. CompCert is not directly executed within Coq. Instead, the Coq code is extracted to OCaml code, then linked with some manually written OCaml code. We now discuss how issues in the Coq implementation may impact the correctness of CompCert.
In addition to the Coq compiler coqc and Coq toplevel coqtop, a proof checker coqchk provides some level of independent checking. Coq is a mature development, however "on average, one critical bug has been found every year in Coq"  [50]. Let us comment on the official list of these bugs. 5 Interestingly, the list classifies their risk according to whether they can be exploited by accident. We can probably assume that the designers of CompCert would not deliberately write code meant to trigger a specific bug in Coq and prove false facts about compiled code: exploiting a Coq bug by mistake in a way sufficiently innocuous to evade inspection of the source code, to accept an incorrect optimization that would be triggered only in very specific cases (to evade being found through testing), seems highly unlikely.
Proofs are checked by Coq's kernel, which is essentially a type-checker for the λ-calculus implemented by Coq (the Calculus of Inductive Constructions with universes). There have been a number of critical bugs involving Coq's kernel, particularly the checking of the guard conditions (whether some inductively defined function truly performs structural induction) and of the universe conditions (Coq has a countable infinity of type universes, all syntactically called Type, distinguished by arithmetic constraints, which must then be checked for validity). These conditions prevent building some terms having paradoxical types. Furthermore, there are options (in the source code or the command-line) that disable checking guard, universe or positivity conditions. For instance, if one disables the guard condition to build a nonterminating function as though it were a terminating one, it is possible to prove "false": Unset Guard Checking.
Issues in Coq Extraction Coq's extractor, as used in CompCert, produces OCaml code from Coq code, which is then compiled and linked together with some other OCaml code. Extraction  [36, 37] , roughly speaking, corresponds to removing non-computational (proof) content, compensating for some typing issues (see below), renaming some identifiers (due to different reserved words), and of course printing out the result. Coq's extractor and OCaml are in the TCB of CompCert. OCaml's type safety ensures that, barring the use of certain features that circumvent this type safety (unsafe array accesses, marshaling, calls to external C functions, the Obj module allowing unsafe low-level memory accesses. ), no type mismatch or memory corruption can happen at runtime within that OCaml code. None of these features are used within CompCert, except for calling C functions implementing the OCaml standard library, and some calls to Obj.
magic, a universal unsafe cast operator, produced by Coq's extractor. Calls to Obj. magic are used by the extractor to force OCaml to accept constructs (dependent types, arbitrary type polymorphism) that are correctly typed inside Coq but that, when mapped to OCaml types, result in ill-typed programs. The following program is correct in Coq (or in System F) but cannot be typed within OCaml's Hindley-Milner style of polymorphism, so uses Obj. magic:  7 Definition m ( g : ∀ { T } , list T → list T ) : Type := (( g ( false :: nil )) , ( g (0 :: nil ))). Extraction m. The following program, which is similar to some code in the Builtins0. v Com-pCert module, uses dependent types Thus, incorrect behavior in the Coq extractor could, in theory at least, produce OCaml code that would not be type-safe, in addition to producing code not matching the Coq behavior.
Is this serious cause for concern? On the one hand, the extraction process is quite syntactic and generic. It seems unlikely that it could produce valid OCaml code that would compile, pass tests, yet occasionally would have subtly incorrect behavior. 9 On the other hand, CompCert is perhaps the only major project using the extractor, which is thus not thoroughly tested. We do not know of any extractor bug that could result in CompCert miscompiling. Another related potential source of bugs comes from the link of OCaml code extracted from Coq and "external" OCaml code. This is discussed in Section 3. 2. Sozeau-et-al  [50]  study an approach to reduce the TCB of Coq by providing a formally verified (in Coq) implementation of a significant subset of its kernel and paving the road for a formally verified extraction.
However, the target language of the extraction (OCaml ?) would still be in the TCB. An alternative solution would be direct generation of assembly code from Gallina, as done by OEuf  [40] ; however parts of CompCert are currently written in OCaml and would have to be rewritten into Gallina. OEuf extracts Gallina to Cminor, one of the early intermediate languages of CompCert, then produces code using CompCert. 10  CertiCoq 11  [43, 42]  also extracts to Clight, which may be compiled with any C compiler.
Use of Axioms in Coq Coq, as other proof assistants, checks that theorems are properly deduced from a (possibly empty) set of axioms. Axioms are also introduced as a mechanism to link Gallina programs to external OCaml code through extraction. Improper 8 Variants of this example correspond to general algebratic data types (GADTs), another recent addition to OCaml's type system not yet exploited by the extractor. 9 Coq's bug tracker lists extractor bugs that, to the best of our knowledge, result in programs that are rejected by OCaml compilers. 10 Other systems meant to generate code from definitions in a proof assistant, generate code directly rather than reuse an existant compiler. This approach is promoted  [29]  with the argument that such a process is safer than textual extraction to, say, OCaml.
This is not so clear to us. On the one hand, extracting (without proof of correctness) Gallina to a subset of OCaml, printing the result, then running the OCaml compiler, surely adds a lot to the TCB. On the other hand, it is typically difficult to get right in a compiler the modeling of the assembly instructions, the ABI, the foreign function interface, as discussed in Section 5. Bugs at that level are caught by extensive testing. Surely, the OCaml code generator, the many libraries using OCaml's foreign function interface, are more thoroughly tested by usage than a code generator used to extract a few specific projects developed in a proof assistant. 11 https://github. com/CertiCoq/certicoq use of axioms may lead to two forms of inconsistency: logical inconsistency and inconsistency between the Coq proof and the OCaml external code.