dataesr/scientific-paragraphs-categorization huggingface dataset:
g. ,  Graham et al. , 2000; Jarzen & Klug, 2010; Smith et al. , 2020)  (Figure  1 ; Supporting Information S1). Most of these use the NLR approach based on palynological datasets, as plant macrofossils from the late Paleocene-early Eocene low latitudes are more rarely preserved, although some exceptions are known  (Herman et al. , 2017; Shukla et al. , 2014; Wing et al. , 2009). We also incorporate data from the mid and high latitudes, for example, southern South America, North America, Australia and New Zealand, and high Siberia (Supporting Information S1). For regions with exceptionally poor data coverage (e. g. , tropical and subtropical latitudes, Antarctica), we also compile and generate MAP estimates from the early middle Eocene (47. 8-∼45 Ma; first half of the Lutetian). Published CLAMP and NLR data were re-analyzed following recent recommendations, so that there is no bias as a result of discrepant methodology.
Specifically, (a) CLAMP-scored fossil leaf assemblages were re-analyzed using up-to-date geographically appropriate calibration datasets  (Kennedy et al. , 2014; Reichgelt et al. , 2019; Yang et al. , 2015) , (b) for both CLAMP and NLR reconstructions, gridded climate datasets from the R package dismo were employed  (Hijmans et al. , 2020) , and (c) NLR analysis was performed using consistently filtered modern distribution datasets to avoid regional overrepresentation (e. g. ,  West et al. , 2020). Modern site coordinates and age constraints were extracted from the original publications.
Note that the MMM contains a different model ensemble for different CO 2 concentrations (see Figure  4  and Table  S1  in Supporting Information S1). Note also that IPSL, INMCM, and NorESM are missing from the moisture budget analysis in this and subsequent plots because the atmospheric variables required were missing from the DeepMIP database. ( -)tm = -∇ ⋅ 1 ∫ cnt -∇ ⋅ 1 ∫ cnt -∇ ⋅ 1 ∫ + RES where "tm" indicates time mean, δ represents the change in each variable between the study interval (i. e. , the early Eocene) and the pre-industrial climate, and the residual term (RES) accounts for changes in the surface pressure bound of the integrals, which is dominated by topographic changes between the Eocene and pre-industrial experiments. With increasing temperatures, atmospheric humidity (q) is predicted to increase following the Clausius-Clapeyron relation.
As such, the subtropics are characterized by overall drier conditions in terms of P-E in the DeepMIP ensemble (Figure  9a ). Extrapolating from this, if early Eocene LTGs were even weaker than suggested by these models  (Lunt et al. , 2021) , Hadley circulation-induced changes may have outcompeted the thermodynamic changes, leading to overall wetter subtropics on zonal average (e. g. ,  Burls & Fedorov, 2017). Although proxy-model bias has decreased over recent years for certain DeepMIP models, early Eocene proxy compilations still suggest weaker global equator-to-pole LTGs (∼14-22°C;  Gaskell et al. , 2022; Evans et al. , 2018; Cramwinckel et al. , 2018)  than those predicted in the DeepMIP model ensemble (∼18-25°C; Figure  1b  in  Lunt et al. , 2021). However, proxy-derived LTG estimates remain associated with large uncertainties due to proxy-inherent uncertainties, the use of different input datasets, and/or the analysis of different time intervals (cf.
Moving forward, we suggest that alternative proxies, for example, clumped isotope-δ 18 O analysis of pedogenic siderites  (van Dijk et al. , 2020) , could help to reconstruct hydrological change in arid and semi-arid environments where plant macrofossils are unlikely to be preserved, and the availability of plant-based terrestrial proxy data will therefore be limited or absent. These caveats will need to be addressed in the future to fully establish the fidelity with which the DeepMIP-Eocene models simulate the tropical and subtropical hydrological cycle response over land. In this study, we proceed by evaluating the models with our synthesis of paleobotanical MAP estimates.
Data Availability Statement The paleobotanical data used to calculate mean annual precipitation (MAP) estimates is available at OSF and associated with a CC-BY 4. 0 license  (Cramwinckel, 2023). Version 1. 0. 0 of the DeepMIP-Eocene model database used to simulate Eocene climate is preserved online (https://www. deepmip. org/data-eocene) and openly available via the University of Bristol Research Data Storage Facility (RDSF)  (Lunt, 2023).
3D-printers enable end-users to design and fabricate unique physical artifacts but maintain an increased entry barrier and friction. End users must design tangible artifacts through intangible media away from the main problem space (ex-situ) and transfer spatial requirements to an abstract software environment. To allow users to evaluate dimensions, balance, or t early and in-situ, we developed BrickStARt, a design tool using tangible construction blocks paired with a mixed-reality headset. Users assemble a physical block model at the envisioned location of the fabricated artifact. Designs can be tested tangibly, re ned, and digitally post-processed, remaining continuously in-situ. We implemented BrickStARt using a Magic Leap headset and present walkthroughs, highlighting novel interactions for 3D-design.
Established CAD (computer-aided-design) software, along with prevalent paradigms of 3D-modeling  [81] , do not necessarily t this use-case, as they often focus on o ering users the highest possible precision. We explored the use of BrickStARt in a user study ( = 16). We found that users immediately got started designing the tangible model and were able to evaluate how a design would behave early on. This happened through tangible, hands-on explorations with the bricks and interacting objects, but also visually, using the digital model displayed in-situ through the HMD. Users with no prior 3D-modeling experience created fewer designs that did not comply with balance or clearance requirements using BrickStARt, compared to Autodesk Tinkercad, indicating the suitability of the paradigm for novice 3D modelers.
g. , LEGO®), after considering alternatives like paper (to sketch on or to fold), malleable plastics (e. g. , as used in  [86] ) or clay. Alternatives to these plastic bricks, such as modeling clay  [74, 93] , are present in the literature. However, interlocking plastic bricks provide a set of advantages, which we deemed appropriate for BrickStARt: 1) The learning e ort that is required to use them successfully, even to solve mechanical problems, is minimal -they can almost be considered a universal language for expression, that is even suitable for children  [72] , and their use has been proposed for learning CAD  [100]  as well. 2) The material properties are comparable to fabricated (i. e. , 3D-printed) objects in terms of density and, by extension, physical behavior. While this similarity does not constitute fabrication-awareness  [92, 95] , it allows users to tangibly experience and understand how the fabricated result may physically behave and provide a worst-case estimate of this behavior.
Reconstruction. Having acquired one or more pro les (or sides of a model), users can now reconstruct it to a digital model to alter, postprocess, and preview it. BrickStARt o ers 3 distinct methods of reconstruction, present in industry CAD software: extrude, lathe, and triplanar. All methods are applicable to 2D outlines or pro les made with the bricks. Triplanar and extrude are additionally applicable to "solid" tangible models (i. e. if the user has built an entire object with the bricks). Creating 2D outlines allows users to focus on relevant features and generally performs better with respect to the reconstruction, as little to no occlusion is present. We embrace this 2D-to-3D work ow, as it allows users to explore and solve partial problems separately and combine them into a nished 3D design.
We chose the 3 methods for a set of reasons: 1) they create useful geometry from 2D pro les, allowing users to solve partial and testable issues in 2-2. 5D; 2) they are present in most, if not all, established toolchains; 3) they save users the e ort of de ning every single portion of the artifact, but rather "generate" geometry. The extrude reconstruction method uses a single 2D pro le or side view and adds an arbitrary depth chosen by the user to it. This approach is common in established software, where features of a 2D sketch are selected and extruded to create a volume (e. g. , linear_extrude() in OpenSCAD  [96]  or "Extrude" in Autodesk Fusion360  [8] ). The process can be seen in gure 4. Fig. 5. Applying the lathe reconstruction method to a brick profile. The user has built a side profile of a vase (1), which is photographed and reconstructed to a 3D mesh, for which the user may choose an axis the profile is rotated around (2), and preview this result in-situ (3).
The lathe reconstruction method also uses a single 2D pro le or a side view and rotates it around an axis to create a volume. It is likewise present in known 3D-modeling software (e. g. , rotate_extrude() in OpenSCAD  [96]  or "Revolve" in Autodesk Inventor  [7] ). This process, as implemented in BrickStARt, can be seen in gure 5. Lastly, BrickStARt o ers users the triplanar reconstruction alternative. It is likewise inspired by functions o ered by screen-based modeling tools (e. g. , "Triplanar" in Nomad Sculpt  [24]  or "ShadowBox" in ZBrush  [64] ), but is a rarer occurrence 8  than lathe or extrude. It is present in tools focused on sculpting (i. e. , more applicable to organic shapes), and less on "hard-surface modeling", and is used for early de nition of shapes. 2-3 pro les or side views are placed on orthogonal planes, extruded, and intersected to yield a 3D object.
In the terminology of Resnick et al. [69] , this indicates a higher skill oor than intended despite o ering a potentially broad range of possible geometries (wide walls  [69] ). In turn, the lathe and extrude functions were well-received and required little explanation, hinting at a low skill oor  [69]. Takeaways for Main Study. The core limitations of the pre-study were 1) the high amount of experience of the participants with respect to CAD software; 2) the absence of a baseline to compare BrickStARt with, and 3) the fact that it focused on objects that interact with their environment physically, but these counterparts (e. g. , plant ⇔ vase) were not part of the setup and task. We furthermore changed our approach to the provided bricks: in the second study, users were encouraged to use multicolored brick assemblies to support recognition, and we added longer bricks to the users' selection to reduce the in uence of having only one brick size available on the design.
Lastly, we solicited comments from all participants, speci cally asking for positive and negative aspects of the respective tools. To better understand users' processes, their actions were recorded on video after explicit consent -Tinkercad tasks were recorded using OBS 11  on a laptop computer and BrickStARt tasks were recorded from a smartphone pointed at the participant's working area (a table). Participants. We recruited 16 participants, across a broader range of users than in our pilot study. Out of the 16 participants, 7 identi ed as female, and 9 participants identi ed as male. Their age ranged from 18 to 33 ( ¯ = 23. 63). 5 participants have used 3D modeling software before, and all 16 had experience with building blocks. 9 had used an AR headset before, but did so for a total BrickStARt: Enabling In-situ Design and Tangible Exploration for Personal Fabrication 429:15 duration below 10 hours (e.
Lastly, we could observe a certain straightforwardness of the participants' use of BrickStARt, as they already knew its language of expression. While an introduction to BrickStARt or Tinkercad was needed -especially for novices -none was required for the task of "solving a mechanical challenge with plastic bricks". Users immediately started to "block out" geometry and test its function using relevant objects (i. e. , plant, phone). Current design tools inherently require explicit learning: their interfaces, but also their paradigms (e. g. , sculpting, programmatic, parametric, or solid modeling). For toy bricks, this is not the case -expressing geometry through these bricks was natural to both novices and more experienced users in our study, in line with established bene ts of tangible interaction  [31, 35] , and echoing insights from works employing malleable modeling materials  [38, 74]  or other construction kits for 3D design  [5, 45].
Ideally, design tools for personal fabrication, operate either in recon gurable media (e. g. , bricks used by BrickStARt or comparable modules  [84] ), create objects that can be deconstructed  [97] , or operate purely digitally, to avoid the fabrication of frequent and permanent physical prototypes. We consider BrickStARt to present an approach that embraces these principles while ideally reducing  [57, 58]  or omitting  [81]  industrial notions of prototyping and iterating.
This would nudge BrickStARt further toward an approach that allows users a fully unrestricted choice of their medium of expression. Additional ways to infer geometry are conceivable for the reconstruction step, such as "Teddy"  [34]. BrickStARt may also bene t from snapping: both to the initial block grid (e. g. , when adding primitives later) or to the physical environment  [61]. Additional operations involving the physical environment in the design process (e. g. , subtraction  [82, 102] ) would also add expressivity to BrickStARt. Furthermore, the use of color-segmentation to extract pro les lays the groundwork for encoding additional information in the tangible model: users may place speci c colors of bricks to encode material properties or interactive elements to be automatically generated by BrickStARt (cf.
higher frequency and more complex evolution scenarios substantiate the need for visualization assistance even to a larger degree than in one-off software development, and, specifically, the use of Visual Analytics  [4]. Visual Analytics is defined as the science of analytical reasoning facilitated by interactive visual interfaces  [4]. The basic idea is to visually represent the data to allow humans to directly interact with the information, to gain insights, and to ultimately make optimal decisions. Broadly speaking, Visual Analytics helps create a path from data to decision. In this process, visualization plays a twofold role  [5] : • as an abstraction medium, by highlighting certain constructs and relationships while ignoring others, • as an interaction medium, by supporting the workflows for decision making.
We extracted data for 234 potentially relevant articles using academic article search engines. After a careful screening of these articles, we identified 41 primary sources. 1 he rest of the paper is structured as follows. Section 2 presents related reviews. Section 3 describes the background. Section 4 introduces the research design, and Section 5 describes the data extraction. Sections 6, 7 and 8 present the results while Section 9 discusses them. Then, Section 10 presents the threats to validity. Finally, Section 11 concludes the paper.
2 ) advocates for making application engineers aware of potential coordination problems right during coding rather than deferring it until merge time. To this end, PeeringHub introduces the notion of 'peering bar' for GitHub. These visual bars reflect whether the codebase of a variant's feature is being upgraded in other variant branches. PeeringHub helps by making developers aware of potential coordination problems right during variant coding rather than deferring it until variant specifics are merged back into the platform master. 3. 1. 3. Feature Identification and Location (FIL)  Setting. Migration from clone & own to an SPL platform. Feature identification aims to determine which features are present, while feature location tackles the relationship between features and assets. Developers may wish to determine which features already exist in the system and which features are implemented in which assets (e.
Functional Testing (FT) Setting. Clone & own and SPL platforms. Regression testing aims at ensuring that an application still functions as expected after any code changes. In view of the impossibility of testing hundreds of features and variants, deciding which features and configuration to test becomes critical. To tame this scalability issue, testers resort to distinct heuristics: hot spots (i. e. , the larger the change, the more likely the impact) or variant similarity comparison analysis to increase test coverage. Example. FeatureCloud (see Fig. 7 ) is a tree-cloud visualization to identify hot-spot features, i. e. , features undergoing substantial change in their codebase, i. e. , ifdef blocks. FeatureCloud depicts feature change along three metrics: LOC (color opacity), scattering (font size), and tangling (position in the word cloud).
Dimension 2: Visualization approach Visualization can be regarded as the intervention to cope with increasingly complex evolution scenarios. By introducing Visual Analytics, decision makers can focus their attention on visualization-enabled analytical reasoning while benefiting from automatic data processing techniques. This dimension can be characterized along with the sort of interaction type  [24]  and the visualization strategy  [10]. FeatureCloud takes the code churn, and extracts the pre-compilation directives from the associated ifdef blocks. On these grounds, the tool generates a word-cloud using feature names as words, and pre-compilation directives as phrases. Nodes stand for features. Color opacity, font size, and distribution of nodes denote the size of the change, the scattering degree and the tangling degree, respectively, for the feature at hand.
Search strategy Search string. Along the lines of Kitchenham et al. [6] , we broke down the question into individual facets, namely, VRS as 'the population', evolution as 'the aim', and 'Visual Analytics' (i. e. , visualization) as 'the intervention'. We searched for synonyms. In addition, we noticed that 'maintenance' and 'evolution' are terms that are arbitrarily interchanged. We also noticed that visualization is often expressed in other forms such as 'visual' or 'visualizing'. Hence, we included visual with a wildcard *. What was more elusive was the notion of VRS as it encompasses areas such as product lines, variability management and configurable systems. This resulted on the following search string: (''evol*'' OR ''maint*'') AND (''visual*'') AND (''product line'' OR ''feature model'' OR ''variability management'' OR ''configurable system'') Academic databases.
Primary sources were obtained by querying the following databases: Scopus, 2  ACM Digital Library,  3  IEEEXplore,  4  Sci-enceDirect  5  and Wiley Online Library 6  (see the top of Fig. 10 ). We did not query Google Scholar and SpringerLink as they lacked the advanced query functionality we needed. Search scope. Search was conducted upon papers' title, abstract, and keywords. To check the validity of the search string, we manually double checked a few articles.
Codes follow: • Raw. When raw elements are used in the visual analysis (e. g. , codebase), at best, tool interactions are limited to provide some sort of data aggregation, • Metric. When metrics are computed from the raw elements as proxies for the analysis (e. g. , number of methods, feature cohesion), • Analysis. When some sort of analysis is being conducted out of the metric (e. g. , data-flow analysis, feature-location analysis). RQ2. 1: Visualized elements. Visualized elements may coincide with the data sources. Sometimes however, elements such as features are abstracted out of the code without the existence of a feature model. RQ3. 3. Tool availability/replicability. We checked the availability of the visualization tool (source code or installer package). First, we searched for an URL in the paper that would take us to the tool.
• Version Control Systems (VCS). Mining VCSs is an already mature area with several mining tools available  [39, 40]. This fact makes even more curious the lack of primary sources resorting to VCS data (such as issue trackers or commit messages). This could be related to the lack of available and open source VRSs. Visualization intervention evaluation. The fact that most tools are only partially validated, if validated at all, shows a worrying situation. This scenario is shared with visualization interventions for one-off development. In their literature review about software visualization, Merino et al. [41]  found that 62% of the primary sources lack a strong evaluation. In the same vein, our review indicates that only 21% of the visualizations are validated in realistic industrial settings.
Conclusions The inherent complexity in the evolution of variant-rich systems calls for dedicated visualizations. To this end, we analyzed 41 visualizations to answer three main questions about (1) the purpose of the analysis being conducted, (2) the kind of supporting visualization, and (3) the maturity of the reported interventions. Analysis wise, we found that researchers tend to overlook 'project managers' role and three evolution scenarios: 'Feature Model Synthesis', 'Analysis of Non-Functional Properties', and 'Architecture Recovery'. Visualization wise, we analyzed visual elements, visualization techniques, interactions, strategies and data sources. We found 11 different visualization techniques where the 'nodelink diagram' was the most popular with 23 primary sources. Unfortunately, scalability seems to be an aspect with high potential for improvement as only 56% of the primary sources implement interaction mechanisms.
When it comes to strategies and data sources, 'temporal snapshot' and 'source code' are the most used approaches, respectively. Overall, we miss studies applying visualization techniques with increasing popularity (e. g. 3D or Virtual Reality) and data sources that are used in other Software Engineering areas (e. g. user feedback or decision knowledge). Finally, benchmarks might also help provide common ground to assess and compare visualization interventions. All in all, Visual Analytics for variant-rich systems looks promising, yet in an early stage of development. We hope this work will have an impact in planning and categorizing future contributions to the field.
We apply our framework in the context of an urban transportation system, and concretely deploy it as a decision making tool and evaluate it on the IPTS of the city of Rennes (France), that is operated by the Keolis company. The main contribution of this paper is the Data-Time framework that allows seamless spatio-temporal data analysis and strategical decision making. Also it extends  [16]  with an evaluation of the predictive model. In particular, we demonstrate the relevance of the micro-learning approach with regard to the macrolearning approach, and discuss both the rationales wrt. the compositional law and the possible limits of the approach. The rest of this paper is organized as follows. We first introduce the DataTime framework (Section 2), and then we present its use in the context of an IPTS (Section 3).
g. , bus line type extrapolated from its identifier, electrical cable resistance computed from its length, etc. ). Metrics are data that are not characteristics, such as measures (speed, volume of water per hour, etc. ) or time related information. Thus, data instances that extend those classes must be able to query data from the Digital Shadow (cf. Subsection 2. 2). The package path represents the abstraction of a path through the graph, that is, a sequence of at least one edge for the thinnest grain. Paths are abstract, as a result one can easily create a path hierarchy if relevant for the targeted application domain (e. g. , transportation networks, supply chains, smart-grids, drinking water networks,. ). Paths allow the building of hierarchical structures within the graphs while offering analysis and predictions scalability using micro-learning for the predictive aspects.