dataesr/scientific-paragraphs-categorization huggingface dataset:
FabSim3 APIs In addition to one-liner commands, FabSim3 can also be used in Python programs through a Python3 API. The API can be accessed using from fabsim. lib. fabsim3_cmd_api import fabsim. The API allows users to access any FabSim3 command-line task by calling the function fabsim(command, arguments, machine). For instance, to run a dummy job on localhost, one can use fabsim(command="dummy",arguments="dummy_test,cores=1",machine="localhost") Within fabsim3_cmd_api, we also provide better-formatted shorthand functions for running ensembles and gathering samples, and we plan to expand the range of shorthand functions as and when the API becomes more widely adopted.
Backends The Backends consist of a range of modules and interfaces that enable FabSim3 to launch, manage and monitor jobs on computational resources, both locally and remotely. They currently consist of three main functionalities: (1) an interface to use SSH (or GSISSH) to Fig. 3. An example to demonstrate how files and folders are organized and transfered to the target machine for execution with ensemble and replica option. (a): the local configuration, i. e. , files and folders, for application (b): the generated files and folder for simple run, without ensemble/replica option (c): the generated files and folder for tow ensembles run of application (d): the generated files and folder for two ensembles and one replica runs of application. Please note that, by default, FabSim3 builds and constructs the required number of ensembles runs based on a default folder, namely SWEEP, located inside the application config directory.
QCG middleware interface The QCG middleware 8  includes a number of key components, such as QCG-Client,  9  QCG-Broker,  10  and QCG-NOW,  11  for job management and execution in HPC centers. The QCG client allows users to access HPC infrastructure and perform calculations on a single or many computational resources in an easy and flexible way  [9]. The QCG client functionalities is available via command line with the interface very similar to the interfaces of popular queuing systems (e. g. SLURM, PBS). It allows submission of different types of jobs, including complex workflows, parameter sweep tasks and array jobs, on single or multiple clusters. The similar functionalities are also available with the QCG-Now which is a desktop graphical program that can be easily installed on laptops or PCs and used to run computational tasks on the HPC infrastructure accessible with QCG services.
Plugin system An important evolution from the original version of FabSim  [16]  is the development of a flexible plugin system. In the original FabSim users would take the toolkit as a whole, and modify it to suit their own needs. Although this led to a good uptake in several domains initially, we discovered that it became hard to transfer improvements across differently modified versions, and that the modified versions themselves could differ in fundamental ways, making code maintenance and improvement even more difficult. In FabSim3 we have therefore opted for a two-layer system where, first, a range of functionalities (Base, Backends and Patterns) are provided to all users, irrespective of their application domains. To complement this, FabSim3 offers a plugin system that allows users to introduce customisations and extensions in a modular and lightweight manner through plugin development.
� fabsim localhost avail_plugin update_plugin Updates a specific FabSim3 plugin from its github repository. � fabsim localhost update_plugin:<plugin_name> remove_plugin Removes a specific FabSim3 plugin from your local system. � fabsim localhost remove_plugin:<plugin_name> a The list of available plugins can be found in https://github. com /djgroen /FabSim3 /blob /master /deploy /plugins. yml. • Plugins provide a central point of implementation for key workflow definitions, to enable consistent use across the plugin user community. (b) Ease of Development: • Plugins are straightforward to develop, extend and support. As a starting point, we showcase this through the FabDummy plugin, which is a minimal platform that users can copy to begin developing their own plugin. • Plugins have a sufficient level of simplicity for average user-developers, such that they can develop and improve plugin code without needing low-level Python programming experience.
Summary of differences with the original FabSim release Aside from the introduction of a plugin system, described in the previous subsection, there have been a lot of functional and performance improvements since our original release in 2016  [16]. These include new features and capabilities, extended and revised the software documentation, and resolved technical issues reported by users. In Table  3  we present the main improvements and changes in FabSim3 toolkit relative to the original FabSim. In addition to all the changes described there, FabSim3 is developed using the Python3 platform and tools, while the original FabSim was developed using Python 2. To clearly communicate the fact that we now use Python 3 instead of 2, we chose to name the toolkit FabSim3, not FabSim2.
Plugins • FabDummy (https://github. com /djgroen /FabDummy) • FabFlee (https://github. com /djgroen /FabFlee) • Added FabUQCampaign plugin, which runs the UQ (uncertainty quantification) samples from an EasyVVUQ campaign via the campaign2ensemble subroutine of FabSim3, submiting the UQ samples as ensemble jobs to remote machines * FabSim3 new features added after first release. Fig. 6. Time required to submit per each job with FabSim3 (with/without QCG-PJ) relative to the number of cores used for job submission. Graph is made using an average of 10 repetition of each ensemble size. Please note that, here we only measure the job submission overhead, so queuing time and job execution on computing nodes are not considered in our test.
Fabmogp fabmogp 20 is FabSim3 plugin for the mogp 21  (Multi-Output Gaussian Process) emulator to automate the simulation execution and Uncertainty Quantification (UQ) workflow of the earthquake simulation. The mogp emulator is a Python package for fitting Gaussian Process Emulators to computer simulation results. The code contains routines for fitting GP emulators to simulation results with a single or multiple target values, optimizing hyper parameter values, and making predictions on unseen data. The library also implements experimental design, dimension reduction, and calibration tools to enable modellers to understand complex computer simulations. To run the actual earthquake simulations, we use the fdfault 22  application, which is a high performance, parallelised finite difference code for simulation of frictional failure and wave propagation in elastic-plastic media.
FabUQCampaign FabUQCampaign 25  is a general interface between EasyVVUQ and FabSim3. The former is a forward uncertainty propagation and sensitivity analysis toolkit. To perform this task, repeated sampling of the computational model is required. Hence, via FabUQCampaign the EasyVVUQ ensembles can be executed on remote supercomputers, including the data transfer to and from the remote host. A Python API is available as well, which allows one to execute FabSim3 command from within the EasyVVUQ Python script.
FabSCEMa The tool in combination with an existing platform for verification, validation, and uncertainty quantification offers a scientific simulation environment and data processing workflows that enable the execution of single and ensemble simulations. It also supports the execution of remotely or locally submitted jobs through the plugin and helps the experts to do several specific annalistic tasks on a local machine or on a cluster or supercomputing platform within the EasyVVUQ and EasySurrogate architectures. It is a fully automated computational tool for the study of the uncertainty in a computational model of a heterogeneous multi-scale atomistic continuum coupling system, a publicly available open-source code SCEMa (https://github. com /UCL-CCS /SCEMa).
Declaration of competing interest The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. 1. Clone or download FabSim3 from https://github. com /djgroen /FabSim3. To clone the code from the GitHub repository, simply type: � git clone https://github. com/djgroen/FabSim3. git 2. To install all required python packages automatically and configure yml files, please go to your FabSim3 directory, and type: � cd FabSim3 � python3 configure_fabsim. py 3. After the installation process, the root FabSim3 directory should be added to both $PATH and $PYTHONPATH environment variables. To make these updates permanent, you need to update both $PATH and $PYTHONPATH variables in your bash shell script.
• execute(put_configs, app) transfers the config files to the remote machine to be used in launching jobs. • env. script = "cannonsim" the env. script variable contains the name of template script file to be used for execution of job on the target machine, which can be local host or HPC resources. This script will be called when the job execution starts, and contains all steps, such as set environment variable, or commands line to call/execute the application. Fig. A. 11(a)  shows the script file, 28 namely cannonsim, for the cannon_app application. At mentioned before, FabSim3 uses a template/variable substitution system 29 to easily generate the required script for executing job on the target local/remote machine. The used system is $-based substitutions, where $var will replaced by the actual value of the variable var, and $$ is an escape and is replaced with a single $.
The API 28 By default, FabSim3 loads all required scripts from templates folder located in plugin directory. Hence, the cannonsim file should be saved in FabSim3/plugins/FabCannonsim/templates directory. 29 https://docs. python. org /3 /library /string. html #template -strings. 30 N. B. by default, FabSim3 builds and constructs the required number of ensembles runs based on a default folder, namely SWEEP, located inside the application config directory. find_config_file_path(app) will return the PATH to the application, here, the return value will be: FabSim3/plugins/-FabCannonsim/config_files/cannon_app • run_ensemble(app, sweep_dir, **args) is an internal low level function to map and execute ensemble jobs. Two mandatory input arguments are: (1) the config/application directory name, and (2) the PATH to SWEEP directory which contains inputs that will vary per ensemble simulation instance.
• FabNEPTUNE (https://github. com /UCL-CCS /FabNEPTUNE) • FabSCEMa (https://github. com /UCL-CCS /FabSCEMa) • FabMD (https://github. com /UCL-CCS /FabMD) • FabUQCampaign (https://github. com /wedeling /FabUQCampaign) • fabmogp (https://github. com /edaub /fabmogp) • FabMUSCLE (https://github. com /djgroen /FabMUSCLE) • FabSMD (https://github. com /potterton48 /FabSMD) • FabCovid19 (https://github. com /djgroen /FabCovid19) • FabCovidSim (https://github. com /arabnejad /FabCovidSim) To support the extension of single scale verification and validation procedures to multiscale settings.
Acknowledgements We are grateful to  Robin Richardson ,  Robert Sinclair ,  Maxime Vassaux ,  David Wright ,  James Suter ,  Daan Crommelin ,  David Coster ,  Tomasz Piontek ,  Bartosz Bosak ,  Alireza Jahani  and  Eric Daub  for their valuable inputs, as well as to all other FabSim3 plugin developers and test users for their contributions. The scientific computations presented in this work have been performed using the Eagle supercomputer at the  Poznan Supercomputing and Networking Centre in Poland. This work has been supported by the  SEAVEA ExCALIBUR  project, which has received funding from  EPSRC  under grant agreement  EP/W007711/1 , as well as by the  VECMA and HiDALGO projects , which have received funding from the  European Union   Horizon 2020 research and innovation programme  under grant agreement nos 800925 and 824115.
• FabNEPTUNE (https://github. com /UCL-CCS /FabNEPTUNE) • FabSCEMa (https://github. com /UCL-CCS /FabSCEMa) • FabMD (https://github. com /UCL-CCS /FabMD) • FabUQCampaign (https://github. com /wedeling /FabUQCampaign) • fabmogp (https://github. com /edaub /fabmogp) • FabMUSCLE (https://github. com /djgroen /FabMUSCLE) • FabSMD (https://github. com /potterton48 /FabSMD) • FabCovid19 (https://github. com /djgroen /FabCovid19) • FabCovidSim (https://github. com /arabnejad /FabCovidSim) To support the extension of single scale verification and validation procedures to multiscale settings. Verification & Validation Patterns (VVP) * • Stable Intermediate Forms (SIF) • Level of Refinement (LoR) • Ensemble Output Validation (EoV) • Quantity of Interest (QoI) Uncertainty Quantifica- tion & sensitivity analysis Patterns (UQPs) *To automate routines for Uncertainty Quantification and Sensitivity Analysis.
Introduction In late 2019 and early 2020, the red supergiant (RSG), Betelgeuse (α Ori), experienced an unprecedented dimming event  (Guinan et al. 2020)  with its brightness in the ⋆ Based on observations collected at the European Southern Observatory under ESO programme 104. 20V6. ⋆⋆ Based in part on observations with ISO, an ESA project with instruments funded by ESA Member States (especially the PI countries: France, Germany, The Netherlands, and UK) and with the participation of ISAS and NASA. ⋆⋆⋆ The reduced MATISSE data are available as OIFITS files at the optical interferometry database: http://oidb. jmmc. fr V band diminishing by approximately 70% at its minimum in February 2020. Multiple hypotheses regarding the physical processes responsible for this great drop in brightness have been proposed.
In this paper, we present VLT Interferometer (VLTI) N-band observations of Betelgeuse with the Multi AperTure mid-Infrared SpectroScopic Experiment (MATISSE) instrument, obtained near the V-band brightness minimum, in February 2020. We tested the compatibility of the cool spot and dust clump scenarios with these data. To this end, we performed 3D radiative transfer modelling of the star and near surroundings. In Sect. 2 we discuss the acquisition of the observations and the data reduction process. We then present the observational analysis in Sect. 3. The setup and analysis of the dust radiative transfer models are described in Sect. 4, and Sect. 5 shows the same for our cool spot model. We discuss our findings in Sect. 6 and finish with a summary and conclusions in Sect. 7.
Observations and data reduction MATISSE  (Lopez et al. 2014 (Lopez et al. , 2022) )  is a four-telescope beam combiner instrument at ESO's VLTI, which covers the midinfrared range from 2. 8 to 13 µm. Observations of Betelgeuse were taken with the small, medium, and large configurations of the 1. 8 m auxiliary telescopes (ATs) during three separate nights in February 2020. Each observation of Betelgeuse was preceded and/or followed by a spectro-interferometric calibrator observation. Sirius and Epsilon Leporis (ϵ Lep) were used for that purpose. For this study we focused on the N-band (8-13 µm) data, which were obtained in the high spectral resolution (R ∼ 220) mode of MATISSE. The log of these observations is shown in Table  1. The data were reduced with version 1. 5. 5 of the MATISSE pipeline 1.
In this work, we did not aim to study the accurate dust mineralogy of Betelgeuse. Hence, to optimise the signal-to-noise ratio on our data, we thus rebinned them to a lower spectral resolution (R ∼ 30). This step was performed in the pipeline on the fringe data before the computation of the interferometric observables. The pipeline outputs are in the form of OIFITS files (version 2), which contain the uncalibrated interferometric observables. Six spectrally dispersed squared visibilities, three independent closure phases (out of four in total), and four total spectra (from the four telescopes) per exposure are included. To calibrate the observations, we used two calibrators, Sirius and ϵ Lep (see Table  1 ). They were taken from the JMMC Stellar Diameter Catalog (JSDC) version 2  (Chelli et al.
That implied N-band correlated fluxes below the MATISSE N-band sensitivity limit with ATs (∼5 Jy) and thus the data were unusable. Figure  1  shows the calibrated squared visibilities and closure phases used in our modelling. The error bars contain two contributions: (1) a short-term one affecting the individual 1-min exposures, as computed by the MATISSE pipeline, and (2) the standard deviation between the merged exposures. We note that the calibration error associated with the stability of the MATISSE N-band transfer function over an observing night is estimated to be about 5% in average seeing conditions  (Lopez et al. 2022) , as was the case for our night (see Table  1 ). In our case, that was smaller than the two other error contributions. Figure  2  shows the (u, v) coverage of the small and medium configuration, and one baseline from the large configuration.
The small and medium configurations probe scales of 60-300 mas and 20-80 mas, respectively. The longer baselines from the large configuration can probe even smaller scales; however, only the shortest baseline of this configuration is usable from these observations, which probes similar scales to the medium configuration. It is important to notice the sparseness of this coverage that prevents us from performing an image reconstruction. In order to compare the flux retrieved from MATISSE to that of the star pre-dimming, we used a spectrum obtained through the Short Wave Spectrometer (SWS, de  Graauw et al. 1996)  instrument of the Infrared Space Observatory (ISO,  Kessler et al. 1996). The version of the ISO data presented in this paper correspond to the Highly Processed Data Product (HPDP) set called 'a uniform database of SWS 2.
Radiative transfer modelling In order to model the circumstellar dust around Betelgeuse, we used the 3D radiative transfer code RADMC3D (version 2. 0,  Dullemond et al. 2012). This code enabled us to input an arbitrary 3D dust density distribution, dust grain properties, and stellar parameters to create cubes of intensity maps, spanning the wavelength range of our observations. The interferometric observables, visibilities, and closure phases were then obtained by running these models through a VLTI simulator, ASPRO2  (Bourgès et al. 2013). From which point, we could directly compare our observations and models. 2021 ) suggests a larger temperature drop. As a drop in temperature during the dimming is expected to be localised (see e. g. Montargès et al. 2021) , we opted for the higher pre-dimming temperature for our models.
Conclusions We obtained MATISSE N-band observations in February 2020 during the Great Dimming of Betelgeuse such as to probe the thermal emission of dust in the immediate surroundings of the star. Ideally, such observations may help to distinguish between the hypotheses proposed to explain this extraordinary decrease in visual brightness. To this end, we modelled the visibilities observed in the small VLTI configuration and examined the closure phases in the small and medium configurations. From our parametric modelling of the VLTI/MATISSE data, we determined the uniform disk diameter of the star between 8 and 8. 75 µm to be 59. 02 ± 0. 64 mas or a radius 1409 +319 -229 R ⊙ at the adopted distance of 222 +48 -34 pc. With the stellar size constrained, our three adopted dust models match the visibility data well: a spherical wind, a spherical wind with a dust clump in the line of sight, and three clumps placed around the star of which one is crossing the line of sight.
Acknowledgements. The authors acknowledge funding from the  KU Leuven C1  grant  MAESTRO C16/17/007. J. S. B. acknowledges the support received from the  UNAM PAPIIT  project  IA 101220  and from the  CONACYT  project  CF-2019-263975. M. M. acknowledges funding form the  Programme Paris Region  fellowship supported by the  Région Ile-de-France. This project has received funding from the  European Union 's  Horizon 2020 research and innovation program  under the  Marie Skłodowska-Curie Grant  agreement no. 945298. This research has benefited from the help of SUV, the VLTI user support service of the  Jean-Marie Mariotti Center  (http://www. jmmc. fr/suv. htm). This research has made use of the  Jean-Marie Mariotti Center Aspro  service (http://www. jmmc. fr/aspro). This research has also made use of the Jean-Marie Mariotti Center JSDC catalogue (http://www.
Then, during the whole sedimentation process spectra are acquired, and collected data are compared to a simple theoretical model describing the sedimentation of a spherical particle in water. The second part of the article presents respectively the basic fluid theory and how to obtain the sedimentation rate of a spherical particle plus the optical resonance aspect. Then, section three is devoted to the presentation of the materials and the thin layer processes together with the procedure yielding the overall experimental setup; this, from the fabrication of the photonic structure by photolithography to the.
After defocalization, the light is directed to a beam-splitter to be redirected to a CCD camera (PulNix) so as to monitor the injection, and to an Optical Spectrum Analyzer (OSA, ANDO AQ-6315E) or spectrometer (Ocean Optics HR4000) driven by an own Matlab computer program for the acquisition of the transduced spectra, FFT calculation plus Lagrange's polynomial simulation onto the peak to obtain FSR. The photonic chip, and both microscope objectives are placed on piezoelectric nano-positioners in order to maximize the precision of the injection. Below, an optical microscopy imaging (obj. ×20) of the four resonators used as the sensing area. The four racetrack-shaped micro-resonators are coupled to an access waveguide and a taper structure is arranged at the input of the latter so as to facilitate the injection by spatially compressing the guided mode.
Materials, chemical aspect and resin, thin layer processes Before experiments, such micro-structures have been designed with Cadence Virtuoso software, the fabrication involving then quartz/ chromium masks (TOPPAN PHOTOMASK Inc. ). This highlights the microtechnological aspects of this study that allowed the realization of this specific sensor as a chip whose parts are produced by thin film deposits and photolithography processes. Thus, the circuits are fabricated in UV210, a polymer with an absorption band at 248 nm in the deep-UV range which allows us to perform deep-UV photolithography. Such a process operating at 248 nm enables the design of more precise and smaller structures than the traditional 'i-line' photolithography performed at 365 nm. First a thermal silica layer is formed on a silicon substrate by wet oxidation method.
Experimental set up, optical/fluidic/nanoparticles (NPs), procedure and measurements Once the set of available circuits is integrated on the wafer, the latter is cleaved with a diamond tip to be incorporated into a dedicated test platform to assess the free spectral range (FSR) values (Fig. 2 (b) ). The resonator is excited by a broadband laser diode with a center wavelength λ 0 = 795 nm and a Gaussian spectrum 40-nm in width. To this end, microscope objectives are used to inject the light in the photonic circuit via the tapers and to defocus the output signal. The transduced signal is directed to an optical spectrum analyzer (OSA, Ando AQ-6315E) or a spectrometer (Ocean Optics HR4000) directly linked to a data acquisition system: then, a processing program developed in Matlab code with control of spectrometer and an interface human/machine is implemented.