dataesr/scientific-paragraphs-categorization huggingface dataset:
13:6 Key SimGrid feature: SimGrid model states are based on a snapshot of process memory. Before continuing on to the implementation of Sthread, there is one additional observation to be made about SimGrid. The model state employed by SimGrid is literally the same as the memory of the Linux process. SimGrid has a variety of heuristics to ignore "garbage memory" (e. g. , uninitialized memory returned by "malloc", or padding within a "struct"). A new model state is recognized as equivalent to a previous model state if the significant process memory is the same. This recognition of previously seen model states helps to control the exponential explosion of states. SimGrid also employs additional techniques from formal verification to control the exponential explosion. Implementation of Sthread: Internally, Sthread currently uses macros in a file sthread.
h for simple source-to-source transformations in order to introduce simcalls to the Sim-Grid scheduler. Two scripts, sthreadcc and sthreadc++, serve as wrappers by which to redirect the line #include <pthread. h> to an sthread-based directory that in turn will include the sthread. h file. Future versions will directly preprocess the programmer's target source code, and also interpose on calls to POSIX threads system calls at runtime. The latter ability will allow Sthread to also support application libraries that make use of POSIX threads. The sthread. h include file translates portions of the programmer's source code into a form that is compatible with the underlying SimGrid. As an example, main is expanded into a new code for main, which then initializes the underlying SimGrid engine and finally delegates control to an auxiliary function, primary_thread, which executes the programmer's application code.
In addition to the standard POSIX system calls, the programmer may insert into the code a call to sched_yield(). This also gets translated into a SimGrid primitive that allows SimGrid to schedule other threads. The programmer is encouraged to place sched_yield() in front of any access to shared memory by the application, so that the current thread may pause and later "see" any modifications to the shared memory by other threads. Note that a transition in Sthread is assumed to consist of a sequence of instructions that are deterministic and non-blocking. This is in keeping with the philosophy that the execution of Sthread should reflect the underlying concurrent algorithm that is being implemented by the multithreaded program. Once the POSIX system calls have been translated for SimGrid, Sthread then relies on SimGrid to produce execution traces.
Priority Inversion and Liveness Properties Next, an example of priority inversion is shown. This example of priority inversion with three threads reflects a famous historical case involving the Mars Pathfinder. That bug was discovered and patched by engineers back on Earth. In a case of priority inversion, a low-priority thread acquires a mutex lock (a bus_lock in the following code), but releases that mutex lock to a high-priority thread on demand. The low-priority thread then blocks on the mutex. Unfortunately, a medium-priority process shares a second resource (protected by a task_lock in the example code below) with the low-priority thread. In this case, the medium-priority lock acquires the task_lock, forcing the low-priority thread to block. The high-priority thread requests that the low-priority thread release the bus_lock, but the low-priority thread is not responding.
13:11 Promela is used as a front end in order to pass a certain state machine for use in the internals of SimGrid. From the viewpoint of the Sthread user, the code related to Promela is: 1. Lines 106 and line 107: MC_automaton_new_propositional_symbol_pointer(): These declare cs and r as parameters associated with the liveness condition. 2. Lines 20, 21, 28, 29, 34, 41, 42: occurrences of cs and r. The variable r is intended to denote that a "request" is active. The variable cs is intended to denote that a thread is in the "critical section". These variables are associated with thread 1, the high priority thread. The Promela-based liveness condition is G(r-> F cs), with the intended meaning in LTL formal logic: "It is always true that if a request is made then eventually the critical section will be entered.
13:14 This example happened to the first author, in his work with the DMTCP project  [2]. DMTCP (Distributed MultiThreaded CheckPointing) is a widely used package for transparent checkpoint-restart of Linux applications. The DMTCP developers had written a lock-free memory allocator for the sake of efficiency. The developers, including this first author, had not observed any bugs associated with this code during the 2-1/2 years after the DMTCP code had been written. During this time, it is estimated that thousands of users of DMTCP were running this lock-free code without triggering a bug. Then a new, reproducible bug manifested itself in an unusual target application that was being checkpointed by DMTCP. The application created and destroyed thousands of threads per second, while allocating and deallocating memory.
The original lock-free implementation in DMTCP is provided verbatim in listing 5 as part of the discussion of section 5. 5. It took the developers of DMTCP a week to identify this bug, known as the ABA problem. With this motivation, a PlusCal/TLA+ model  [19]  of the program was written to verify the intended solution. The PlusCal program required 103 lines to model the lock-free code. And since it produced an execution trace for the bug only with respect to the PlusCal model, it was not possible to directly employ GDB to analyze the execution trace. Nevertheless, even with the added confidence due to the PlusCal program, the first author continued to worry about the possibility of human error in translating such snippets of DMTCP code to PlusCal. This was the motivation of the first author in investigating SimGrid, and then developing a collaboration to develop Sthread.
ABA Bug Next, the code for the lock-free algorithm for memory allocation, as described in section 5. 4, is analyzed. Here, Sthread is faithful to the example in the DMTCP project that brought this to our attention. In the DMTCP project, the target application was observed to crash, and Sthread has discovered a thread schedule leading to a crash. Sthread discovered a program crash using its default max-depth of 1000. The reported thread schedule 2;2;2;2;1;2;2;1 corresponds to an allocate, another allocate and a deallocate by thread 2, while thread 1 is trying to allocate. The pattern corresponds to the ABA problem earlier described in section 5. 4. The choice of calls to allocate or deallocate was verified by printing application source line numbers where there are calls to sched_yield(). Finally, during deallocate, a thread has a choice of which of the buffers that it has allocated that it wishes to deallocate back to the stack.
Related Work The Sthread implementation is based on SimGrid  [21, 7]. SimGrid is a long-standing project that appeared in 2003  [20]. It is a simulation package that offers explicit-state model checking for formal verification. The process memory is considered as the state of the process. The SimGrid developers call this stateless model checking since the model state is not derived from the target program variables themselves. The state of all of process memory serves as the model-checking state. SimGrid includes sophisticated heuristics to determine what parts of process memory represent garbage and should not be included in a test for state equality. SimGrid has been used for verification of large-scale distributed systems  [6] , network simulations  [32] , and MPI  [11]. The last example includes the SMPI interface, which was the inspiration for the Sthread interface of the current work.
In related work,  [23]  describes transformations of process memory (i. e. , reordering of memory regions) that can be used to decide when the memory state for two processes should be considered semantically equivalent. There is one other well-known approach that often employs the idea of modeling the memory of a process. This is the use of Context-Bounded Analysis (CBA) in formal verification. However, the majority of CBA approaches use a compiler such as LLVM to instrument the addresses of variables of the target program. The direct use of program variables as state facilitates such back ends as SAT-based symbolic algorithms (testing for arbitrary program input) and Bounded Decision Diagrams (BDDs)  [1]. The general goal of CBA is different from that of Sthread. CBA methods typically have the more ambitious goal of capturing buffer overruns, writes to arbitrary addresses in memory, bugs in memory allocators, writes after freeing a memory region, and other bugs often associated either with low-level code of with C/C++ and other "unsafe" languages.
Hence, while the goal of CBA methods is to formally model preemptive context switching. This has the advantage of being more general than Sthread. But it also has the disadvantage of incurring a still greater exponential explosion of states than Sthread, since thread context switches are assumed to be possible at any point at all in the code. In order to capture this more ambitious goal, the CBA methods employ a source-to-source transformation of a multithreaded program into a sequential program, in which a non-deterministic program variable, current_thread, indicates which thread 13:19 executes the next statement. After each statement, a "goto" is executed to go to pc  [current_thread]  and that pc is then incremented. Thus, any thread can preempt after any statement. An example of this approach is Lazy-CSeq  [16, 17].
DIVINE prefers general liveness properties rather than the application-specific liveness properties of Sthread. In both cases, virtual machines interpret an intermediate representation, byte code generated by the LLVM compiler. In both cases, the use of an interpreter implies slower execution of the target program during model checking. Hence, it is not in vivo. Further, while Sthread uses all of process memory as model state, and then subtracts memory that may be garbage (e. g. , uninitialized malloc memory), these approaches begin with only the memory of the program variables, and then (in the case of DIVINE), the interpreter tracks additional memory that is allocated by the target program. See  [13]  for a classification of model checking that includes some of the ways that model state may be represented.
In the case of CBA, pancam  [34]  has employed CBA with the well-known SPIN explicit-state model checker  [34]  at the back end. LLVM byte code is interpreted in a virtual machine and the LLVM byte code allows the system to track program variables as its state. Another notable approach is DIVINE  [3, 4, 30] , a large, long-standing project now in its fourth version  [3]. The citation  [30]  is particularly recommended for an overview of DIVINE. DIVINE takes the approach of no annotations to the target C/C++ code. Thus, DIVINE includes a large number of general LTL-based properties that must be checked for the entire program. (In contrast, Sthread allows the programmer to add 13:20 program-specific C/C++ variables to express program-specific liveness properties to be checked. See section 5.
3. ) While DIVINE directly checks input C/C++ programs, it follows the approach of pancam in compiling to LLVM byte code (IR, or intermediate representation), where it is interpreted by the DIVM virtual machine (in version 4, whereas formerly the interpreter was integrated into the formal verification layer). While the capabilities of DIVINE are impressive, it suffers from two failings with respect to the goals of this paper: (i) the use of an interpreter for intermediate byte code means that it is slower than Sthread's execution of native machine code, and the DIVINE interpreter is limited in not being able to handle most kernel calls or any external calls to a GPU, FPGA or other CPU accelerator  [30, page 2] ; and (ii) the pre-compilation phase to compile general LTL formulas results in larger Büchi automata, which are both CPU-intensive and consume a lot of memory.
In comparison, Sthread directly tests for properties such as deadlock, and can use simpler LTL formulas to test liveness since it allows the programmer to annotate the target program with applicationspecific livelock properties of concern only to that program. In fairness to DIVINE, issue (i) (interpreted execution) is partially mediated by DIVINE's re-implementation of the libc and pthread libraries for compatibility with DIVINE's interpret. Issue (ii) (precomputation of general LTL properties with Büchi automata) is partially mediated by DIVINE's use of multi-core and clusters for compilation of the Büchi automata  [5]. An early example related to the CBA approach (although not known under that name at the time) is Chess  [25]. Chess modeled multithreaded system calls, but it was not formally a model checker since it did not have states.
Conclusion and Future Work It has been shown that Sthread correctly handles a broad variety of concurrent algorithms for multithreaded programs. Examples were shown for deadlock, program crash, assertion failure, and livelock. Sthread allows the programmer to add small in-vivo annotations in C/C++ to the target program. This provides a reasonable balance between allowing the programmer to provide hints to Sthread for better efficiency, and maintaining a light burden for programmers with no experience in formal verification. The examples covered here also strongly overlap with the exercises in a beginning course covering multithreaded programming. This is meant to suggest the pedagogical advantages of using Sthread to allow beginning students to gain immediate feedback through execution traces of failure modes, as they seek to debug their homework.
Dynamic partial order reduction (DPOR) is a classical technique used to make explicitstate model checking more efficient. SimGrid already employs DPOR in other domains, and SimGrid will be extended to support DPOR for the POSIX threads domain. While the work of this paper is based on the C/C++ language, Sthread is both language-independent and compiler-independent. It operates directly on machine code, rather than a compiler-generated intermediate byte code. This will be demonstrated in future work, by extending the Sthread implementation to support verification of multithreaded APIs for other languages. In order to better support pedagogy, a future work will develop a series of graduated exercises in implementing POSIX threads programs and to implement concurrent algorithms with multithreading.
Acknowledgements The work of the first author was partially supported by  NSF  Grant  OAC-1740218. The work of the second author was partially supported by the  Inria Project Lab (IPL) Hac Specis. The two together are partially supported by a grant from  Inria  as an  Inria Associate Team (Équipe Associée d'Inria)  with the title "FogRein:  Steering Efficiency  for Distributed Applications". The authors are grateful for the detailed comments of the referees and for the careful reading and comments by  Gregory Price.
Section 2 discusses the main characteristics of our five nearby galaxy samples (JINGLE, HRS, KINGFISH, HAP-LESS, HIGH). In Section 3, we analyse the observed scaling laws for the dust, gas and metal content of these five galaxy samples. In Section 4, we subdivide our local galaxy sample into six bins according to their specific Hi gas masses, and compare their average scaling laws with DEUS to infer how their dust and metal content has been built up across cosmic time. In Section 5, we summarise our conclusions. In the Appendices, we outline the method used to model the dust masses (Appendix A), detail the datasets and methods used to infer galaxy specific properties (Appendix B), describe how we infer customised star formation histories (SFH) for galaxies at different evolutionary stages (Appendix C), discuss the specifics of DEUS (Appendix D), while a list of acronyms and symbols is presented in Appendix F, and additional Tables and Figures are presented in Appendices E and G.
ACKNOWLEDGEMENTS We would like to thank the anonymous referee for her/his suggestions which have improved the presentation of the fitting methods and results reported in this paper. IDL gratefully acknowledges the support of the  Research Foundation -Flanders (FWO). LCH was supported by the  National Science Foundation of China  ( 11721303 ) and the  National Key R&D Program of China  ( 2016YFA0400702 ). MJM acknowledges the support of the  National Science Centre, Poland  through the  SONATA BIS  grant  2018/30/E/ST9/00208. The James Clerk Maxwell Telescope is operated by the East Asian Observatory on behalf of The  National Astronomical Observatory of Japan ,  Academia Sinica Institute of Astronomy and Astrophysics , the  Korea Astronomy and Space Science Institute , the  National Astronomical Observatories of China  and the  Chinese Academy of Sciences  (Grant No.
Results Travel history uncovers more realistic phylogeographic patterns. To focus on the early dynamics of SARS-CoV-2 spread, we analyze a data set consisting of curated genomes available in GISAID on March 10th, 2020 (n = 282). Having collected travel history data for over 20% of the sampled patients, we extend phylogeographic reconstruction methodology to incorporate this source of information (cfr. "Methods"). Specifically, we augment the sampled genomes from known travelers with their recent travel location and either the time of their return journey or estimated time of infection (see below). Critically, we include travelers returning from severely undersampled locations, including Italy, Iran, and Hubei, China, where the virus was first identified. In our Bayesian analysis of the complete data set, we model a discrete diffusion process between 44 locations: 29 countries and 15 locations within China, including 13 provinces, one municipality (Beijing), and one special administrative area (Hong Kong).
In Fig. 1 , posterior support for the nodes in the maximum clade credibility (MCC) tree is represented by the size of the node circles and the support across all nodes is summarized as a histogram. This illustrates that only a limited number of clusters are reasonably well supported. Poor phylogenetic signal is also illustrated by likelihood mapping analysis (Supplementary Fig. S4 ). This renders a single phylogenetic tree summary inadequate to interpret phylogeographic history. We sidestep this problem by studying spatial trajectories that marginalize over phylogenetic variability, in the ancestral history of single taxa. In Fig. 2 , we consider a case study involving the spatial path of a virus that was collected in Switzerland in February 2020 (EPI_ISL_413021). As summarized in Fig. 2a , the Swiss virus is positioned within a cluster of viruses primarily from Europe that has been the subject of controversy.
The inclusion of genomes associated with a Hubei travel history also strengthens the original Hubei ancestry in the phylogeography, as trajectories appear to coalesce earlier in Hubei. Although the trajectory suggests an introduction into Italy from Germany, the support for this is not overwhelming and solely due to the single genome sample from Germany basal to the Italian cluster. We return to this transmission hypothesis in the next section. In a second case study, we consider a virus from Australia sampled in February 2020 (EPI_ISL_412975). The virus is positioned within a clade of other closely related viruses from Australia (lineage B. 4, Fig. 1 ), some of which were sampled from travelers returning from Iran  22. Using sampling location alone does not provide any support for Iranian ancestry, since the data set does not include any genomes directly sampled from Iran (Fig.
The inclusion of unsampled taxa also provides more resolution on the Hubei ancestry of the Iran-Australia case study in lineage B. 4 (EPI_ISL_412975). We estimate a similar trajectory as the analysis using travel history without unsampled taxa (Fig. 3 ), but with a more recent coalescence in Hubei because of unsampled Hubei taxa clustering basal to an Iranian clade (Fig. 5 ). The genomes from four Australian travelers returning from this country, one direct contact, another Australian genome without travel history, as well as a genome from a traveler returning from Iran to New Zealand are effectively embedded in unsampled Iranian diversity. The most basal virus in this clade is from a Canadian traveler returning from Iran. Although the basal nature of this virus is not well supported, there is good posterior support for the monophyly of all the sampled genomes in this clade.
6b, c ). In the travel-aware analyses, European countries experience more introductions from Italy, as well as more directly from Hubei. As also illustrated by the specific examples (Figs. 2  and 3 ), the considerable number of secondary transmissions from Italy and Iran is revealed by using travel history data (Fig. 6b ). The substantial addition of unsampled taxa from these relatively undersampled locations does not further contribute to this pattern (Fig. 6c ), but adding unsampled diversity from Hubei does remove an unexpected dispersal from The Netherlands to Taiwan (Fig. 6b, c ). Retrospective genome availability fills specific sampling gaps but still benefits from incorporating travel history. We assembled the 282 genome data set based on genomes available in GISAID on March 10. Because many sequences with sampling times before this date have become available retrospectively, we also compiled a larger data set by downsampling the available genome sequences with a sampling time up to March 10 ~4 months after this date.
We focus on 43 of the 44 locations represented in the 282 genome data set, but include Shanghai instead of Fujian (cfr. "Methods"). The downsampling procedure mitigates sampling bias for many locations but not all (Supplementary Fig. S5c ), and we therefore incorporate travel history for the same subset of genomes as in the 282 genome data set. The travel-aware analysis of the 500 genome data set (Fig. 6d ) results in highly consistent overall dispersal dynamics compared to the previous travel-aware reconstructions without or with unsampled diversity (Fig. 6b, c ), e. g. , in terms of the seeding patterns from Hubei, and the considerable number of secondary transmissions from Italy and Iran. Because of the larger sampling in this data set, a limited number of additional dispersal events are inferred.
Most importantly, we demonstrate that the travel-aware approach can dramatically improve phylogeographic inferences about the specific country-to-country paths followed by the SARS-CoV-2 virus during the early stages of global spread. As expected, the inclusion of travel history data is most informative when travelers are arriving from locations, such as Italy and Iran that experienced early SARS-CoV-2 outbreaks, but for which few genome sequences were available, resulting in large gaps in the phylogeny. In addition to illustrating the benefit of including travel information in such cases, we also demonstrate that the travel-aware reconstructions are associated with a higher posterior predictive accuracy. We retrieved travel history data for ~20% of the early available genomes, but many more travel-based introductions may be undocumented.