dataesr/scientific-paragraphs-categorization huggingface dataset:
Results We evaluated our method and its variants for ablation studies, as well as the baselines listed in Section 5. 1. The test set of the dataset contains 1,485 samples, where 547 of them have a built time label, and 371 have an exactly built year label. Our evaluation uses only these 371 samples as it is not trivial to evaluate errors based on dynasty and century labels. We employed mean absolute error (MAE) as our error metric. Table  1  shows the performances of all methods in comparison. Rows 1, 2, 3 and 6 are the inductive baselines. Nearest Neighbour Search (row 1) and Gaussian Process Regression (row 2) did not perform well, while ResNet50 Regression w/o fine-tuning (row 3) gave competitive performances. This implies that training with the MSE loss can benefit a lot, and our backbone provides rich cues about Buddha statues even though it is trained on human faces; yet end-to-end training helps.
These results may also suggest that the relationship between the feature space and the built year space is not simple, which can support the use of our KL divergence-based loss and regularisation term. Rows 4 and 5 are the performances of transductive baselines. GC-NBoost Regression  [9]  shows a better performance when compared 1 https://github. com/ermongroup/ssdkl to SSDKL  [12] , but both methods did not perform as well as other methods. For SSDKL, we consider that the original feature vector obtained from our backbone did not have sufficient cues about the built years and the error accumulated in the iterations. GCNBoost Regressor suffers from the sparse connectivity between samples in the test set and those in the training set since we added edges between the samples with exactly same built years; therefore, the features cannot be well trained.
CONCLUSION In this work, we proposed a method to estimate the built year of Buddha statues from only their face images. We faced four main challenges to solve this task: First, the images in the dataset were collected from digital scans of 5 different books, which introduced many artefacts and distortions. Second, the dataset is quite small, containing only 4,949 facial images. Third, only 30% of samples in this small dataset are labelled. Finally, this dataset contains two types of labels: exact built years and the range of built years (i. e, dynasty and centuries) estimated by historians. To overcome those challenges, we modelled the labels in the form of Gaussian functions, which provided a unified built time representation for training. We also designed a new loss function to handle Gaussian functionbased built time representation as well as unlabelled samples.
2015). To this aim, our implementation exploits an automatic SAT solver. SAT solving is an active field of research  (Heule et al. 2021; Bjørner et al. 2015; Hutter et al. 2017; Audemard et al. 2016 ) and tools exist that compute, more or less efficiently, a solution for an input formula, or fail if the formula is not satisfiable. Hence, by feeding the formula encoding an ambiguity question to a SAT solver, we can obtain an answer to it. In our implementation, we use the Z3 SMT solver (de Moura and Bjørner 2008) (that includes a SAT solver) developed by Microsoft Research and freely available under the MIT license. The python code of our implementation is publicly available  (ter Beek et al. 2019c) ; it accepts FTSs in the format. dot as input and all example models used in the remainder of this paper are provided.
FTS representation Our algorithm assumes that the considered FTS is represented by the global data structure fts that includes four fields: 1. states stores the set of all states in the FTS; 2. transitions stores the set of all transitions in the FTS; 3. initial stores the initial state of the FTS; 4. fm stores the formula FM (introduced before Example 2 in Section 3), which is a formula in B(F ) that represents the feature model of the FTS. Each state is represented by a data structure that includes three fields: 1. in trs stores the set of incoming transitions of this state; 2. out trs stores the set of outgoing transitions of this state; 3. hdead is a Boolean flag used to record whether this state is a hidden deadlock. Each transition is represented by a data structure that includes four fields: 1.
In this case, it would suffice to add one or more transitions to leave state s 20 in a meaningful way. This is the solution opted for in  Classen et al. (2013) ,  Dimovski et al. (2015) ,  Dimovski et al. (2017 ), ter Beek et al. (2017 ), and Dimovski and Wasowski (2017) , which use the specification in fPromela of the complete mine pump model as originally distributed with SNIP  (Classen et al. 2012 ) and its re-engineered successor ProVeLines  (Cordy et al. 2013a ) (https://bitbucket. org/maxcordy/provelines-cora/) or their translations for mCRL2  (Cranen et al. 2013; Bunte et al. 2019 ) (http://www. mcrl2. org/) or VMC  (ter Beek et al. 2012; ter Beek and Mazzanti 2014)  (http://fmt. isti. cnr. it/vmc/). Basically, three transitions are added to the system FTS of Fig. 11  from state s 20 to the initial state s 6 to cover the cases in which features from the subset {ll, ln, lh} are missing, viz.
The results show that only a fraction of the runtime of the current implementation is needed for deadlock detection, ranging from 6. 06% for the FTS of the coffee/soup machine to only 2. 97% and 3. 59% for the complete mine pump and Claroline FTSs, respectively. All the experiments presented in this section were performed on a Mac Pro (Late 2013) 3. 7 Ghz Quad-Core with an Intel Xeon E5 processor with 10 Mb L3 cache and 64 Gb (four 16 Gb) of 1866 Mhz DDR3 ECC memory. All the experiments were performed five times each and the average time and memory usage of each was collected and reported in the tables. We used Python 3. 6.
Introduction Around 46 % of observed exoplanets are located within 20 times the radius of their host star (using the database exoplanet. eu 1 , e. g. Schneider et al. 2011). Such a configuration leads to important star-planet interactions, affecting the dynamics of these compact systems  (Cuntz et al. 2000). The study of these interactions is therefore crucial to understand the population of currently observed planetary systems and their evolution. The study of the orbital architecture of exosystems then improves our understanding of such processes and constrains the evolution models we rely on. The secular evolution of a star-planet system is essentially driven by stellar tides  (Leconte et al. 2010) , unless star-planet magnetic interactions develop due to the motion of the planet in the ambient magnetized stellar wind, which may have a significant role in the evolution of the system  (Strugarek et al.
2014 (Strugarek et al. , 2015 (Strugarek et al. , 2017)). In particular, the dissipation of tides in the host star, by ensuring angular momentum exchanges be-1 http://www. exoplanet. eu, the database was consulted on December 18, 2020 to provide this estimate. tween the star rotation and the planetary orbit, is thought to play a major role in the secular evolution of orbital architecture  (Bolmont & Mathis 2016; Benbakoura et al. 2019) , and star-planet obliquity  (Lai 2012; Damiani & Mathis 2018). Furthermore, as the reservoir of angular momentum of the planet is less important than the one in its orbit, the planet tends to be synchronized within a few thousands of years. The gravitational response of the star to the planet leads to two kinds of flows: the non-wave-like equilibrium tide  (Zahn 1966; Remus et al.
Grid of models for low-mass stars To study the influence of stellar structure and evolution on tidal dissipation in the radiative zone of low-mass stars, we rely on grids computed with the 1D stellar evolution code STAREVOL (see  Siess et al. 2000; Lagarde et al. 2012; Amard et al. 2019 , for an extensive description) for masses ranging from 0. 4 to 1. 4 M at a solar metallicity Z = 0. 0134  (Asplund et al. 2009). We study all phases from the PMS to the top of the RGB. As shown in Fig. 4  (top-left panel), the star, completely convective at the beginning of the evolution, is in contraction during the PMS. A radiative core grows after the Hayashi phase and a mass transfer occurs from the convective envelope to the radiative zone, leading to an increase then a decrease of the density at the core-envelope interface during the PMS (top-right panel).
Acknowledgements. We would like to thank the referee,  Jim Fuller , as well as  Allan-Sacha Brun  and  Antoine Strugarek  for helpful comments and suggestions regarding our work. J. A. and S. M. acknowledge the PLATO CNES funding at  CEA/IRFU/DAp. J. A. acknowledges funding from the  European Union 's  Horizon-2020 research and innovation programme  (Grant Agreement no. 776403  ExoplANETS-A). S. M. and J. A. acknowledge funding by the  European Research Council  through the  ERC  grant  SPIRE 647383. L. A. acknowledges funding from the  European Reseach Council AWESoMeStars 682393.
A design approach for the synthesis of architectures The pre-design methodology proposes by the authors is summarized in Fig. 4. It consists in two successive steps and aims at offering a general manner to design a system architecture during pre-design, by relying mainly on the synthesis of architectures. Regarding the ISO/IEEE 42020 standard, this approach covers the "Architecture conceptualization" and the "Architecture elaboration". Step 1 proposes the formal modeling of a design problem using DEPS. Step 2 focuses on solving this problem in DEPS Studio. Step 1 begins with the textual specification of requirements expressing the design problem in a natural language. This specification is the result of a Trade-off between various stakeholders, including the client, the designer, engineering discipline experts as well as the project manager.
In particular, this language must be able to model the structure of the problem and to manipulate ordinal and cardinal quantities, that are essential for engineers and experts. To facilitate the development and the use of CSP, the scientific community has developed a number of available libraries such as Choco  Lorca et al. (2014) , IBEX IBEX (2020) or RealPaver  Granvilliers and Benhamou (2006). Those libraries are built using object-oriented programming languages as C++ or Java. However, these are programming languages (dedicated to programmers) and not modeling language (dedicated to designers and engineering experts). Our purpose is therefore to adopt a highlevel modeling language and an integrated environment which can on the one hand model and solve the design problem but which is also specially dedicated to designers.
For the resolution part, this language will use Constraint Programming on mixed domains. To our knowledge, the only two solutions that currently exist for this purpose are Clafer  Bak et al. (2016)  and DEPS Yvars and Zimmer (2014). However, Clafer has two limits: 1. Clafer's solver, i. e. Choco, is not integrated into the language. It is necessary to transform Clafer models to Choco, which makes it extremely difficult to develop Clafer models. Indeed, if results produced by Choco are not satisfactory (solving problems), models modifications can only be done in Java and not in the initial Clafer modeling language. 2. Choco, is designed to handle domains of discrete variables while design problems often involve mixed variables. For example, the battery design problem used to illustrate this article essentially involves real continuous variables (physical quantities).
Thus, DEPS is a language better suited for modeling design problems because it does not have these two limitations. The DEPS research project aims at developing a textual formalism to specify design problems, DEPS, and a dedicated framework to model and solve them in the same environment DEPS Studio. DEPS is a Domain-Specific Modeling Language (DSML) dedicated to the formalization of design problems of systems (including embedded, real-time, electrical, cyber-physical systems). DEPS is intended for pre-design and aspires to deal with sizing, configuration, architecture generation and allocation problems, that can be mixed-type and ill-posed (including over-constrained). DEPS is a formal, declarative, object-oriented language. Contrary to some relatively theoretical formalisms, such as Axiomatic design  Suh (2001)  or CK-theory  Hatchuel and Weil (2009) , the DEPS formalism is the result of an inductive approach carried out in partnership between industrial and academic researchers.
Advances around DEPS started with very concrete industrial questions and, thanks to an analysis of the limits and strengths of the tools and languages currently available, led to a first proposal for a language and an associated IT tool (DEPS Studio). The results of this work, far from being definitive, are in constant progress, according to the new needs in the face of new design problems. Dedicated to designers in industrial design departments, the approach, the language and the implementation tool are designed in a pragmatic way so as not to be rejected by potential users. Previous versions of DEPS have already been employed to formalize continuous (in the field of robotics  Yvars and Zimmer (2014) ) and discrete (in the field of integrated avionics Zimmer et al. (  2020 )) design problems, but many more different examples must be treated to see advantages and limits of problems modelling with DEPS.
The organization in problem modeling projects (regrouping Problem and Models packages). 3. The compilation of design problems (built-in compiler). 4. The solving of design problems (built-in solver). The consistency of each model is first checked by the compiler (syntax, lexicon and models dependencies). A single instance of the problem is created and other subdefinite elements are created from this instance. The debugging of the models is directly realized in DEPS. It does not rely on the language used by the solver. The errors capture occurs during this step, which allows the designers to correct their models if necessary, before solving. After compiling, solving can be considered. Then, DEPS models are compiled in DEPS Studio, to produce an internal and generic computational model for solving.
Conclusions The purpose of this article is twofold. First, it presents an approach for pre-designing physical systems through a modelbased approach based on a synthesis process. One of the main objectives of this work is to propose a methodology and a framework that is dedicated to industrial designers facing concrete and complex design problems. In this context, the vision embraced is at the same time constructive, inductive and upgradable. One of the key aspects of this approach is to encourage the formalization of the design requirements and the design problem in order to accommodate the point of view of the different stakeholders (customers, designers, experts, project leaders). This methodology is based on the problem specification language DEPS and its modeling/solving integrated environment DEPS Studio.
The DEPS language exploits the many advantages of object oriented languages (reusability, decomposition, generalization/specialization, inheritance) and the resolution steps use Constraint Programming. This approach is advisable as soon as we design structured systems (functionally and/or structurally) and that we are able to establish a set of design properties such as equations, algebraic and/or logical inequalities. This does not serve the purpose of pure innovation or creativity. Second, this methodology is illustrated on a use case based on the design of a Li-ion battery for electric vehicle. The relevance and effectiveness of this approach are demonstrated on this example. It is obvious that, as with any new method, a phase of learning the language and computer tools is necessary and that it will be easier for users who are already familiar with object-oriented modeling.
A total of 23 different alert products are implemented, using 1 geostationary and 13 polar-orbiting satellite platforms, 3 external existing service, and 2 EU and 2 regional ground-based networks. This allows for the identification and the tracking of extreme events. The EUNADICS-AV EWS has also shown the need to implement a future relay of radiological data (gamma dose rate and radionuclides concentrations in ground-level air) in the case of a nuclear accident. This highlights the interest of operating early warnings with the use of a homogenised dataset. For the four types of airborne hazard, the EUNADICS-AV EWS has demonstrated its capability to provide NRT alert data products to trigger data assimilation and dispersion modelling providing forecasts and inverse modelling for source term estimate.
As illustrated in Fig. 17 , the current approach is based on both EURDEP data and the EMERCON (Emergency Convention) messages produced by IAEA through the WMO Regional Specialised Meteorological Centres (RSMCs). Both data sources are ultimately released by STUK after filtering the EURDEP data and collecting the EMERCON information (from ZAMG). STUK    finally provides the information to the automatic alerting system developed in EUNADICS-AV. Following its national responsibilities, STUK has implemented elevated GDR alerting software based on measurements available in the EURDEP system. It consists of separate Python scripts that handle data collection, alerting and database maintenance functions. This work at the national level has been further extended to fit the purpose of the EUNADICS-AV EWS.
The alerting condition is checked in 10 min intervals. A nuclear threat is declared and an alert is created if two nearby measurements show dose rate values higher than the calculated background. Alerting based on a single measurement is not advisable because very often there are high dose rate values caused by other factors, such as broken Geiger-Müller tubes, for instance. When an alert in GDR data is identified, a text message file is created. This alert message is transferred to a ZAMG-hosted FTP (File Transfer Protocol) server, and an email notification is sent to the hosting platform of the EUNADICS-AV EWS at BIRA. This message transfers data information and a link to an HTML (Hypertext Markup Language) page, which points to an interactive map automatically zoomed to the alerting stations.
An example of the EURDEP notification, taken from the EUNADICS-AV March 2019 exercise (cf. the example of the Etna eruption exercise of  Hirtl et al. , 2020a)  is shown in Fig. 18. The detailed information link leads to an HTML web page containing the map with zoom and pan features (Fig. 19 ). The map contains current real online measurements of the EUR-DEP network. However, and as a note of caution, currently in the EURDEP system, most European countries do not share validated radiological monitoring data in NRT, and gaps may appear per country or time window. In the case of a GDR alert, an alert data product is created by the EUNADICS-AV EWS, in a homogenised format (see Sect. 4. 4. 3).
Overview of the EUNADICS-AV EWS The EUNADICS-AV EWS is built on the SACS system  (Brenot et al. , 2014) , which provides NRT satellite data products (SO 2 columns and ash and aerosol index) to aviation stakeholders in the form of maps and email notifications. The SACS system (https://sacs. aeronomie. be, last access: 5 November 2021) is dedicated to volcanic hazards. The development achieved by EUNADICS-AV concerned an upgrade of the SACS system (volcanic emission) and the extension to other airborne hazard (dust, smoke and radionuclide clouds), with the creation of new alert products. The EUNADICS-AV EWS is a prototype multi-hazard system which has expanded the SACS system and creates new functionalities (based on existing mechanisms of SACS) by using the following: (1) key satellite products from IASI/MetOp-A, IASI/MetOp-B and IASI/MetOp-C; SEVIRI/MSG-9; TROPOMI/Sentinel-5 Precursor; SLSTR/Sentinel-3A and SLSTR/Sentinel-3B; and MODIS Terra and Aqua sensors; (2) ground measurements from EU networks (EARLINET and E-PROFILE) and regional networks from volcano observatories (IMO and INGV-OE); and (3) existing services (VONA messages, EU-RDEP, RSMC EMERCON messages and NASA FIRMS).
A new functionality obtained by the EUNADICS-AV prototype EWS is (4) the creation of netCDF alert data products (NCAP files) dedicated to the integration in the dispersion model and the interest for ATM stakeholders. The development of the pre-alerting mechanism is based on email notifications (volcanic and radionuclide cloud hazards only) and the creation of homogenised tailored data alert products and alert maps, as illustrated in Fig. 20. Initially, the SACS system was built integrating NRT data products (SO 2 columns and aerosols/ash indexes) from seven polar-orbiting instruments (OMI, OMPS, GOME-2A, GOME-2B, AIRS, IASI-A and IASI-B) in a single monitoring and alerting system for volcanic eruptions. This system considers only satellite instruments on board polar-orbiting satellites. Figure  20  shows the new additional data information ingested by the EUNADICS-AV EWS.
NRT products from satellite, ground-based and in situ platforms/instruments are provided by EUNADICS-AV partners and external data sources (Tables  2  and 3 ) and transferred to the EWS. The blue block in Fig. 20  indicates the multi-source input data (ash, SO 2 , dust, radioactive and smoke cloud ob-  servations). The structure and the choice of the data products considered in the EUNADICS-AV EWS relies on the user requirements and risk assessments presented in Sect. 2. The automated EWS (including routine data products) applies its own mechanisms to create NRT images and to issue alerts. The development of the EUNADICS-AV EWS uses inputs from an existing EWS addressing continuous monitoring of volcanic ash and SO 2 plumes (messages from VONA) and the detection of fires (NASA FIRMS) and radioactive plume (EURDEP) from NRT observational-data portals.
The system compares the time of observations with the processing time. If there is a delay of less than 8 h, a notification is issued. Then, alert data products are created and archived. If the "warning status" is already ON (i. e. ongoing event determined using existing pool of active alert pixels; see Sect. 4. 1. 4), no notification is issued, but an update of the event is noted in the alert data archive. This set-up allows for providing timely information to the users and also to avoid issuing too many notifications (maximum one notification per region per 24 h). When an alert is issued by the system, the first step is to check whether this represents a new event (start of natural airborne hazard -SNH) or it is linked (LNK) to an ongoing event. At this stage, a characterisation of the source of the hazard can be obtained (a) directly from the alerting process (e.
4. 6. 2). A new detection of alert pixels (status SNH or LNK) is associated with the implementation of an event, which includes the reference number (date of the first alert) associated with alert products and links to quicklooks from EARLINET, E-PROFILE or other observations from the volcano observatories. The collection of netCDF alert data products (NCAP files) and the associated data directory of an event type (ASH, SO2, DST, SMO or NUC, respectively, for ash, SO 2 , dust, smoke and radionuclide clouds) is created, with the objective of triggering dispersion model. Access to EUNADICS-AV partners and key users is assured via FTP or HTTPS (Hypertext Transfer Protocol Secure) connection.
Alert products For each alert/event issued by the EUNADICS-AV EWS, the associated event type is created/updated, and the alert archive is completed. Figure  22  shows the three kinds of alerting production related to an event. The diagram in Fig. 1  shows the links between the blocs of activities of EUNADICS-AV, and the red arrows characterise the specific EWS processing chain (see also Fig. 20 ), from observation retrievals, data harvesting and triggering with the implementation of alerts to the delivery of alert data products for modelling integration and ATM stakeholders.