dataesr/scientific-paragraphs-categorization huggingface dataset:
For a simulation with 50,000 elements, we noticed for TOUGH3 a plateau in performance when reaching roughly half of the available cores on the Windows workstation, with a speed increase of about 4 (Fig. 1a ). On a Linux workstation, the increase is observed up to the limit number of cores (increase up to 10-fold). Figure  1b  shows the performance of TOUGH3 for a simulation with 800,000 elements: the speed increase is similar to the smaller mesh. All our tests were done on a workstation (i. e. , a shared memory system), as FLAC3D, and hence the final coupled code, is not yet supported on high-performance computing (HPC) clusters (i. e. , a distributed memory system). The test simulation has also been designed to be a typical case for running a coupled problem (i. e. , with relatively small number), and we decided to test in the most common conditions for a user.
This implies creating output files, which are dealt with in serial, thereby compromising the speed increase. Note that TOUGH3 has demonstrated a strong scaling on distributed memory systems (  [21] , Fig. 1 ), in a case with 2. 88 million elements. Hence, the limited performance shown in Fig. 1  is related to the operating system (OS). For the given simulation, a common simulation case as highlighted above, the performance improves on a Linux OS (with the exact same hardware as for the Windows case), but does not reach the potential scaling we could have on HPC clusters  [21]. The performance of FLAC3D was evaluated for three versions (v5, v6, and v7) only using the Windows workstation with up to 32 threads (i. e. , same as the number of cores with the given hardware configuration). Figure  1c  and d  show the speed increase, with v7 being sensibly faster than v5 and v6 for the 50,000 elements simulation, while v6 and v7 perform similarly for a simulation with 800,000 elements.
e. , for the initial conditions), then FLAC3D is paused during TOUGH3 execution and the model state kept in the memory, thereby avoiding overhead caused by restoring/saving the mechanical state at each TOUGH3 time step; & Use of Python to read/write coupling files in FLAC3D and calculate internal variables. By using NumPy  [32] , this can produce up to 34× faster execution (10× in average) in variable allocation compared to the previously used FISH scripting  [29]. The strategy proposed here is general and can be applied in both Windows and Linux environments. All the coupled simulations presented here were carried out on the Windows virtual workstation that allows using up to 32 MPI processors/threads. The general coupling strategy between any TOUGH-code and FLAC3D is based on file exchange to share variables and/ or properties.
Such arrays (pressure, temperature, saturation and capillary pressure) are written to file TOU_FLA by the IOProcessor, together with a flag  (1). The IOProcessor performs this entire stage in serial, while all the other n MPI processes are idle. During this process, FLAC3D is idly waiting for the flag to change. Then, FLAC3D (i) reads the TOU_FLA file (in serial), (ii) solves for mechanical equilibrium (in parallel), and (iii) writes the FLA_TOU file to transfer data to TOUGH3 (in serial), and modifies the flag  (2). At this stage, the subroutine invoked previously by TOUGH3 is waiting for FLAC3D to finish execution, then the IOProcessor serially reads the flag and the FLA_TOU file and distributes the variables/ properties (bulk modulus, Biot's coefficient, strain, and stress) to all n MPI processes.
Finally, the parallel computing can restart with the calculation of mechanically-induced changes of flow properties and with continuation of the flow iterations to finish the current time step. When TOUGH3 is at the last time step, it will issue a flag (3) that FLAC3D will interpret and save the final state in a binary file. The mechanical state as well as the flow variables can also be saved at predefined times during execution. The use of Python within FLAC3D allows for easier handling of arrays (e. g. , mapping of a given variable or extra postprocessing computation), and also for handling and personalizing the entire output functions, making the use of standard TOUGH3 output functions redundant. performance on two workstations operating on the same hardware configuration but running on different OS, for a computational mesh with 50,000 and 800,000 elements, respectively.
5x faster compared to the previous version only owing to better I/O handling and use of Python in FLAC3D. Due to parallelization overhead (communication and domain decomposition), the speed up clearly depends on the size of the mesh, with an increase of up to 2× faster for a coarse mesh with 15,000 elements and up to 5× faster for a relatively fine mesh with 800,000 elements. Interestingly, for all the cases the performance does not improve after reaching 16 cores/threads. This is consistent, however, with the performance observed for TOUGH3 on the same hardware configuration (Fig. 1a  and b ), which is attributed to conflict with the operating system processes, as discussed above. FLAC3D is not affect by this behavior, so in general we obtain a better performance in terms of speed-up for TOUGH3-FLAC3D compared to TOUGH3-only, although the absolute running time is much smaller for the latter.
The main goal of the current work is to demonstrate how the code has improved compared to previous implementations, rather than to show the best conditions (i. e. , OS choice) to simulate coupled processes with TOUGH-FLAC. For a fair comparison with the previous versions, it was necessary to test the current coupling approach on a Windows-based system. We expect the overall performance to significantly increase on a Linux-based system, although still limited to hardware setup for a shared-memory workstation as compared to a cluster. The possibility to run problems with very large number of elements in the computational mesh will enable a more detailed description of the thermo-hydro-mechanical processes occurring at depth. We have provided in this work two examples: one relates to fault reactivation during CO 2 sequestration, and the second one relates to nuclear waste disposal.
Acknowledgments The research was funded by a research agreement between  ENSI  and  SED  and by a  Swiss National Science Foundation  ( SNSF) Ambizione Energy research grant  ( PZENP2_160555 ). Funding for LBNL was provided by the  Spent Fuel and Waste Disposition Campaign, Office of Nuclear Energy of the U. S. DOE , under Contract Number  DE-AC02-05CH11231. The authors are grateful to  Michael Ruthenberg  and the  BenVaSim community  for useful discussions. Comments from two anonymous reviewers helped improving the paper.
Ground-based Time-series Photometry We conducted ground-based photometric follow-up observations for TOI-712 as part of the TESS Follow-up Observing Program 2  (TFOP; Collins 2019). We used the TESS Transit Finder, which is a customized version of the Tapir software package  (Jensen 2013) , to schedule our transit observations. The observations are described below and summarized in Table  1.
Spectroscopic Classification We extract the effective temperature (T eff ), surface gravity (log g), and metallicity ( Fe/H ) of TOI-712 from the CH-IRON spectrum by matching against a library of observed spectra that have been previously classified by SPC  (Buchhave et al. 2012) , with interpolation performed via a gradientboosting regressor implemented in the scikit-learn python module. We find T eff = 4767 ± 50 K, log g = 4. 63 ± 0. 10, and Fe/H = -0. 15 ± 0. 08. The projected rotational velocity, v sin i , is derived following  Gray (2005)  and  Zhou et al. (2018) , fitting broadening kernels to the instrumental, macroturbulent, and rotational line profiles. We estimate v sin i = 2. 0 ± 1. 0 km s -1 and v mac = 1. 4 ± 1. 0 km s -1 , though the instrumental resolving power is only 3. 7 km s -1 ; for such slow rotation, these estimates may suffer systematic offsets.
ACKNOWLEDGEMENTS We thank  Adina Feinstein  for helpful discussion regarding stellar flares in TESS data. SV and SNQ acknowledge support from the  TESS Guest Investigator Program   G03268  and  NASA  grant number  80NSSC21K1056. MNG acknowledges support from the  European Space Agency (ESA)  as an  ESA  Research Fellow. This work makes use of observations from the LCOGT network. Part of the LCOGT telescope time was granted by  NOIRLab through the Mid-Scale Innovations Program (MSIP). MSIP is funded by  NSF. Some of the observations in the paper made use of the High-Resolution Imaging instrument Zorro obtained under Gemini LLP Proposal Number:  GN/S-2021A-LP-105. Zorro was funded by the  NASA   Exoplanet Exploration Program  and built at the  NASA Ames Research Center by Steve B. Howell, Nic Scott ,  Elliott P.
Data requirements of the MILP model Below we present a description of the real, processed, and simulated data used in this case study. For more details on the database, we created a Mendeley repository (see MendeleyRepository) that contains files written in AMPL, which are located inside a folder called 'Data'. These files present all the data used in the two analyses performed in Section 6 (Analysis 1 and Analysis 2). In addition, the real, processed, and simulated data are provided in different folders.
Real data Most of the real data were provided by SHIFT SpA, whereas the remaining data were collected from published articles that also evaluated retail case studies. SHIFT SpA is a firm that optimizes the shift schedules of multiple retail companies across South America. Real datasets contain information on the following parameter groups: (i) staff costs, (ii) personnel planning process, and (iii) certain staff demands. In the Mendeley repository, the real data (i) and (ii) are presented in 3 files according to the three store sizes considered in the case study (i. e. , SS = 4, 5, 6 departments). We highlight that the two analyses tested in Section 6 used these same three files. Also, and only for the first analysis, real data (iii) are presented in 3 files, which resulted from combining the demand profile DP 1 and the store sizes.
Recall that, as already mentioned in Appendix B, the weekly demand hours in each department and week (r ls ) associated with the demand profile DP 1 were obtained from a real instance of demand. Now, the values of the parameters associated with the real data (i) and (ii) are described in detail. Regarding the cost parameters, a minimum training cost was assumed for each hired multiskilled employee (US$1 -year/multiskilled employee). Henao et al. (2015 Henao et al. ( , 2016 Henao et al. ( , 2019) )  and  Porto et al. (2019 Porto et al. ( , 2020) )  explained that this assumption allows interpreting the model results as an upper bound of the potential contribution of multiskilling. That is, if a minimum training cost is considered, we can find the maximum number of multiskilled employees required to minimize the understaffing/overstaffing costs.
Processed data The processed data refers to the model sets that must be built to evaluate the case study. These sets are W, L w , W l , W out l , and W in l. Recall that Appendix A describes the construction process of these skill sets. In addition, in the Mendeley repository, these processed data are provided in 3 files according to the three store sizes considered. We also highlight that the two analyses tested in Section 6 used the same processed data.
Simulated data The case study considers two simulated datasets, one for each analysis tested in Section 6. Both datasets are associated with the weekly demand hours in each department and week (r ls ). For the first analysis, a dataset presents the staff demands associated with the demand profiles DP 2 and DP 3. Recall that, as already mentioned in Appendix B, the demand profile DP 1 was built with real data, whereas demand profiles DP 2 and DP 3 were simulated. Thus, this first dataset presents 6 files classified by: (i) Store size (SS = 4, 5, 6) and (ii) Demand Profile (DP 2 , DP 3 ). For the second analysis, a dataset presents 270 files classified by: (i) Demand Profile (DP 1 , DP 2 , DP 3 ), (ii) Store size (SS = 4, 5, 6), (iii) Coefficient of variation (CV = 10, 20, 30%), and (iv) Instance identification number (10 staff demand instances for each of the 27 scenarios, which resulted from combining store sizes, demand profiles, and coefficients of variation).
Computational tests and discussion In this section, we present the computational tests along with the results and discussion of the case study presented in Section 5. Model (1) -(  11 ) presented in Subsection 4. 1 was written in AMPL language and the problem was solved using the commercial CPLEX software running through the NEOS-server for a maximum of 8 h (restrictive). In  Czyzyk et al. (1998)  and  Dolan (2001)  more details about the computational characteristics of the NEOS server are provided.
The FAIR principles have been accepted globally as guidelines for improving data-driven science and data management practices, yet the incentives for researchers to change their practices are presently weak. In addition, data-driven science has been slow to embrace workflow technology despite clear evidence of recurring practices. To overcome these challenges, the Canonical Workflow Frameworks for Research (CWFR) initiative suggests a large-scale introduction of self-documenting workflow scripts to automate recurring processes or fragments thereof. This standardised approach, with FAIR Digital Objects as anchors, will be a significant milestone in the transition to FAIR data without adding additional load onto the researchers who stand to benefit most from it. This paper describes the CWFR approach and the activities of the CWFR initiative over the course of the last year or so, highlights several projects that hold promise for the CWFR approaches, including Galaxy, Jupyter Notebook, and RO Crate, and concludes with an assessment of the state of the field and the challenges ahead.
Canonical Workflows to Make Data FAIR The above indicated paradoxes illustrate the challenges of generating a domain of FAIR compliant Digital Objects (FDO)  [6]  that are necessary for flourishing data science. The gap between practices on the one hand and workflow technology and FAIR compliance on the other hand is great and begging for new approaches. Researchers are slow, even reluctant to incorporate FAIR in their daily practice since this would require considerable adaptations and re-developments-which would reduce productivity for some period. They even may not know how to do this. Using current workflow technology would imply dependency on software development experts which are scarce or on the need to learn appropriate software skills. These options are not attractive for most researchers.
), since the assigned PID should refer persistently to all information aspects that are needed to find, access, interpret and reuse its bit-sequence and since its "type" as part of its metadata will enable linking it to procedures (methods, operations). It should be noted that the FAIR principles do not make statements about "openness" of data. In contrast, due to their binding capability  FDOs allow applications to build in security measures controlling access to content. However, despite its relevance security aspects are not touched further in the present paper and in the present special CWFR issue. It should be said here that programmatic scripts providing fragments of more comprehensive workflows are already widely used in system management and in various scientific domains, but they in general cover workflow tasks that are not the subject of variations.
Some experts will prefer to write personal scripts or use bespoke manual steps, while others will prefer to rely on orchestrating their automatic workflows with readymade components which are taken from open software libraries  or libraries of accessible commercial platforms . As indicated, Galaxy  [11]  and BioVeL  [12]  can be seen as relatively recent solutions that support the different approaches. Galaxy and Jupyter are quite generic, whereas BioVeL was an example targeted towards a specific domain and community. While Galaxy and BioVeL are intended to offer components that can be reused to orchestrate workflows, Jupyter Notebook  [13]  is a general-purpose interpretative framework that is meant not only for quickly developing and testing scripts but also acting as a mechanism for documenting and publishing code and results.
Canonical Workflows to Make Data FAIR When workflow frameworks are designed to offer a rich component landscape, generic methods for describing the interactions between the components of the workflow and with the workflow management must be provided. Often, proprietary workflow languages and database solutions are being used internally. These were not designed with FAIR compliance in mind, but primarily to support the efficient operation of the workflow management system (WfMS). Various export formats often enable the exchange of documents or artefacts being created at the end. When all tools and frameworks, however, support the creation and usage of FDOs as first-class citizens on the Internet, a much higher degree of interoperability would be achieved, independent of changing technological fashions.
In many cases it will be necessary to develop wrappers to make the existing components "CWFR ready". It is obvious that this will be an incremental process that can only be comprehensibly and comprehensively enacted if many researchers see the need and advantages of supporting automation and of creating a FAIR domain of exchangeable digital objects. These ideas are well-known in the workflow technology developer community, yet with some exceptions the solutions have not yet been addressed from the point of view of the researchers and this is essential for achieving breakthroughs. There are some solutions such as, for example, Weblicht  [18] , that were designed to help the naive computer users. Weblicht allows linguists to orchestrate typical natural language processing (NLP) processes, e.
g. , "identify named entities" in a text. The user enters a text in a specific language which is identified by the workflow machine and then appropriate operations are offered from a library starting with part of speech tagging. After each step the machine offers the remaining valid choices of components, i. e. , the machine knows about the previous actions which are documented in the metadata and therefore knows which operations are possible for the given output at that step. All interaction is thus at a level that linguists easily understand. However, Weblicht, like other comparable tools, only addresses a specific set of applications. The chosen metadata format is specific for this application domain and FAIR compliance was not a primary objective, i. e. , all was contained in one specific DO.
Many presentations in these meetings have then been transformed into papers in this special issue.  We note that this paper mainly reflects on the meetings and the discussions which have taken place thus far as part of the CWFR initiative and which can be found as fuller contributions to this special issue. The discussions during the workshops reported below and some paper contributions indicate that currently much more training courses on workflow technologies are given. They range from generic extensions of Python to Jupiter courses which are well perceived by many young students to training courses about complex systems such as Galaxy. In this special issue and this paper these efforts are not in the focus although they are very important for improved take-up in the future.
The Galaxy developers provide modules that can do this transformation between a set of well-known tools. For other tools, new transformers would have to be developed. All process information, the workflow script, the state of the workflow, references to information being used, etc. are maintained in a relational database. For documentation purposes, reports can be generated in a variety of formats, which range from PDF documents that can be stored in Zenodo up to structured information using description standards such as RO-Crate. Where feasible, Galaxy makes use of the EDAM ontology  [23]  which has been developed by the bioinformatics community. This brief description indicates that the concept behind Galaxy matches closely with the ideas behind CWFR and it is not surprising that Galaxy is being used widely in the biomedical community, with some attempts at use beyond that community.
Some researchers create and execute new workflows, but many reuse prefabricated workflows for a variety of computations. Galaxy contributes greatly to closing the gap between workflow technology and researchers. However, we see a few limitations and can draw some major lessons: • Galaxy is supporting only synchronous workflows at this moment, i. e. , asynchronous operations which occur when processes are, for example, waiting on human intervention or on the end of the process to be executed in parallel, are not (yet) supported. • The workflow and state documentation is included in an optimised relational database which is not designed to enable sharing (and therefore switching between environments, for example). Currently, comprehensive reports are only provided at the end of workflows. • The integration of tools is not a trivial task and requires experts to create the required wrappers.
Canonical Workflows to Make Data FAIR including the transformation of parameters between processing actions. Since it supports generic programming languages, Jupyter would allow building a reusable workflow framework such as sketched by CWFR. However, the setup of software libraries, the choice for metadata descriptions, the processing of collections, the generation of appropriate and FAIR compliant documentation with the help of FDOs, etc. , would have to be developed by a community interested to extend Jupyter  [28]. As a generic framework, Jupyter poses few restrictions but requires significant intervention by professional software developers in order to become an easy-to-use framework for canonical components interacting via FDOs. It seems to be a useful framework for researchers with modest programming skills to implement workflows that are being used personally or in a small team of known users.
However, for complex tasks such as executing workflows on High-Performance Computing (HPC) machines, or for use by a large community of potentially unknown users, building blocks would have to be provided by experts. It was agreed that (1) it cannot be assumed that all researchers become workflow programmers and (2) in general it should not be expected that researchers trained in Python will go on to become professional software developers capable of tackling more complex tasks and producing robust, reliable, sharable and maintainable code.
In most cases such workflow projects are undertaken where IT experts can lead the development efforts. This is especially true when generic frameworks such as Jupyter Notebooks are being used beyond comparatively simple pipelines which imply few restrictions but require proper software development skills. On the other side of the technology spectrum are workflow applications such as for example Weblicht, Galaxy and YARD  [29]  that address specific tasks, albeit with some restrictions. The example of Galaxy shows that, although it can be characterised as general-purpose across biomedical sciences, it is still an effort to integrate existing tools and to solve the import-export transformation challenges which requires expert knowledge, even in that single domain. For ready-made processes where the tool integration and the import-export challenges have been solved, the use of Galaxy indicates that this can lead to considerable uptake.