Coline Schiell

Stéphane Portanguen

Valérie Scislowski

Camille Rivard

Pierre-Sylvain Mirade

Thierry Astruc

Impact of storage conditions and time on iron distribution and state in a 3D-printed hybrid food

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Impact of storage conditions and time on iron distribution and state in a 3D-printed hybrid food

Coline SCHIELL 1,2 , Stéphane PORTANGUEN 2 , Valérie SCISLOWSKI 1 , Camille RIVARD

BACKGROUND MATERIALS AND METHODS

Iron deficiency is the leading cause of anemia, which affects about 25% of the world's population [1]. Several approaches are being explored to address these deficiencies, including the development of new iron-rich foods in which iron would be provided naturally through the nutritional richness of the ingredients involved.

RESULTS

Commercial 3D food printer However, iron absorption is related to complex mechanisms and depends on the form of iron, heme iron (HI) or non-heme iron (NHI), and on the other components of the food. Moreover, the chemical and textural properties of the food may be affected by storage conditions and time [2,3]. In this context, this study investigated the time-course chemical changes at the microscopic scale in a hybrid food composed of liver and lentils, comprising several forms of iron.

XRF maps and corresponding iron profiles

Plot correlation between iron and other elements obtained from XRF maps

Cuts Powder

Timepoints for analysis:

Acknowledgments:

Several Fe populations depending on the samples suggesting different bondings between iron and other elements:

• Binding of iron to sulfur proteins? • Colocalization of iron and phosphate in ferritin core?

  This study highlighted the effect of time in storage and MAP composition on oxidation mechanisms in animal/plant hybrid food containing different iron forms. Most of the changes were observed from day 5 for foods stored under O 2 -MAP, which resulted in a change in the distribution and forms of iron in animal and plant parts as indicated by the decrease in HI and the modification of the atomic environment of iron.

Liver•

  Overall higher concentration of iron in the foods that were stored under O 2 -MAP • More heterogeneous distribution of iron in plant part which was mainly accumulated in the amyloplasts [4] Chemical forms of iron varies depending on the mixtures source (specific spectral signature) and on the storage time Prospects: Identification of iron oxidation states D14 coline.schiell@inrae.fr/coline.schiell@adiv.fr Tel.: +33(0)4 73 98 53 80 / +33(0)6 83 46 85 72 D5 D14 Changes in the atomic environment of iron depending on the storage conditions funded by the Association Nationale de la Recherche et de la Technologie (2021/1267) and Bpifrance (grant No. DOS0191062/00). The authors acknowledge SOLEIL for provision of synchrotron radiation facilities (prop. 20220297).

  3,4 , Pierre-Sylvain MIRADE² & Thierry ASTRUC 2

	References

1 ADIV (Association pour le Développement de l'Institut de la Viande), 63039 Clermont-Ferrand, France ; 2 Université Clermont Auvergne, INRAE, UR370 Qualité des Produits Animaux (QuaPA), 63122 Saint-Genès Champanelle, France ; 3 Synchrotron SOLEIL, L'Orme des Merisiers,

Saint-Aubin, 91192 Gif-sur-Yvette, France ; 4 INRAE, TRANSFORM, 44316 Nantes, France


Marie Le Guilly

Claudia Capo

Jean-Marc Petit

Vasile-Marian Scuturici

Rémi Revellin

Jocelyn Bonjour

Gérald Cavalier

Attempt to better trust classification models: Application to the Ageing of Refrigerated Transport Vehicles

Keywords: Prediction model, Industrial machine learning, Applications, Functional Dependencies

CEMAFROID is a company with a french delegated public service, delivering conformity attestations of refrigerated transport vehicles. It studies the ageing of those vehicles, depending on several physiochemical and mechanical factors, for which physical models have been proposed by researchers in thermal engineering. The DATAFRIG R database records more than 300 000 attestations of vehicles over 80 attributes, opening the opportunity to predict the ageing by building a numerical model using machine learning methods. During the development of such a model, several classical questions appeared, regarding the data quality, the field reality and the mistrust of domain experts. In this paper, we propose to use the notion of functional dependencies to address the aforementioned model's limitations. In particular, we investigate how FDs could help, especially using their counterexamples, that turn out to provide meaningful examples of such limitations, easily interpretable by domain experts. Interestingly, the existence of such counterexamples in the dataset is a way of demystifying the numerical model with the experts, by giving them back the control over their own data. This approach has been tested with domain experts from CE-MAFROID, with many positive feedbacks. It is worth noting that this attempt to better trust classification models is not limited to a particular application, and could be generalized to others.

Introduction

Refrigerated transport vehicles' main objective is to supply consumers with good quality and safe perishable products. In this context, CEMAFROID offers testing and calibration services, and has been designated as an approved body for issuing conformity attestations for refrigerated transport vehicles. To this end, researchers in thermal engineering have access to a large database, DATATFRIG R , recording data about more than 300 000 attestations for refrigerated vehicles, with tables spanning over almost 80 attributes. Among all these attributes, the thermal insulation of the body is a basic element of the refrigerated equipment, characterized by an "insulation coefficient" denoted K: it is very important as it may be controlled as required by the ATP (the international Agreement for the Transport of Perishable foodstuff). The lower the K coefficient the better, but due to the ageing of the vehicle, it increases over time.

To control it and allow the vehicle to continue to transport perishable food, its thermal insulation is measured again after 12 years of service. The ratio between this value and the initial value allows too define the ageing of the vehicle.

To explain the variability in the ageing of refrigerated vehicles, several studies have looked at the problem to identify factors to explain it, and propose physical models for the ageing. [?] presented the factors playing a role in the ageing process. As stated by [?], the ageing of an insulated enclosure for a refrigerated vehicle is mostly due to the permeability of the foam to the gases, to the condensation of water into the foam cells and to the increase of the percentage of the broken cells. Ageing of refrigerated vehicles also has a mechanical component due to the movements on the road, the routes covered and the payload. A statistical analysis carried out in [?] highlighted the influence in the ageing rate due to the rails and to the refrigerating units.

But whereas all these studies rely on physical models to analyse the problem, the amount of data available in the DATATFRIG R makes it possible to build a predictive model, using machine learning techniques: such a new approach is a way to tackle the problem from a different angle, to possibly identify new causes for the ageing of vehicles, and to confront new results to the one obtained with physical models. Shifting from a physical to a numerical model is indeed a big change of paradigm, especially for the domain experts that mainly design and work with physical models. The ML techniques might even generate scepticism. In this study, we therefore paid strong attention to give guaranties about the model, and to explain its limitations. It was important to explain why the considered data could (or not) produce a satisfying model, so that the experts that would use it afterwards could trust it and understand why its decisions made sense. To this end, it appeared that functional dependencies could be a very powerful tool to model knowledge on the classifier [?].

Functional dependencies (FDs) are a well-known and widely studied notion over the years, at the foundation of the theory for relational database design (see [?]), expressing constraints and relationships between two sets of attributes. In the setting of this paper, we propose to use FDs to model the possible limitations of a predictive model, by considering that FDs can determine whether a model can actually exists over a relation, before actually trying to determine the model using a classification algorithm. Indeed, a classification model seeks an optimal function, with respect to a given error measure, that maps features to a class. This process relies on a strong hypothesis, which is the existence of a function from the features to the labels, and only seeks to determine such a function. However, in a complementary way, FDs can be seen as a way to determine if such a function even exists. A detailed study of the link between FDs and classification is available in [?]. We only underline here that when there exists a function from a feature vector X to a label Y , it follows that the function dependency X → Y is satisfied.

Thus, for a classification problem, it seems logical to first verify the existence of a function using FD f eatures → class. Moreover, understanding what tuples prevent the FD from being satisfied can lead to improve the results, if the identified blockages can be explained and fixed by the domain experts. This is where the notion of counterexample is useful. Counterexamples identify pairs of tuples for which the classifier will never be able to perform correctly, as for the same input, it will always predict the same output. Understanding where these counterexamples come from, and what can be done to avoid having such tuples in the dataset, is then an important tool to improve the classification performances.

These notions were used in an application to CEMAFROID's data, for which the notion of counterexamples appeared to be central for the discussion with thermal engineers. In this paper, we expose how we presented such counterexamples to the experts in thermal engineering, in order to give them back the control over their own data, by explaining some of the limitations of the classifier. The discussion that followed allowed to identify several possible causes for the existence of counterexamples, that are exposed in this paper, along with possible solutions to remove them. We also measured the proportion of counterexamples in the dataset, by using metrics on the error of FDs in a relation. The feedback obtained during this discussion highlighted several interesting research problems related to classification, for which FDs could be useful, such as feature engineering and data cleaning.

Paper organisation Section ?? presents the available data and the first numerical model built on it. Section ?? presents the approach used, and the results of a discussion with thermal engineers, based on the analysis of counterexamples to a FD in their dataset, before concluding in section ??.

Predicting the ageing of Refrigerated Transport

Vehicles Data

Refrigerated transport vehicle's data

At 31 December 2017, based on the Datafrig R data, the French fleet counted 110 000 refrigerated transport equipment with a valid ATP certification. These equipments are divided into different categories, the main ones are: vans (vehicles with a total weight allowed in charge smaller than 3.5 tons), trucks (vehicles whose total weight allowed in charge varies from 3.5 to 29 tons) and semi-trailers (vehicles with total weight allowed in charge higher than 29 tons). The Datafrig R database is managed by Cemafroid and contains all the ATP in-service equipment in France.

From this database, sample of only 1158 highly curated data could be extracted from the 109 122 refrigerated equipment registered in the Datafrig R database. These 1158 data represent different in-service vehicles of different firms, tested after twelve years in the laboratory of Cemafroid. For each of these vehicles more than 80 features are known. Ten of the most important features, from a domain expert point of view, were analyzed including the K 12 , the corresponding K p , the type of vehicle, the body manufacturer, the nature of the refrigerated enclosures and their isolation, the use of the vehicles and the different types of transport to which they may be subjected. Most of the available features are therefore categorical. Our selection criteria for the sample of 1158 vehicles were based on data quality requirements applied on the ten selected attributes (or variables): no null values, no outliers, and no duplicates. It is worth mentioning that we rely on knowledge domain provided by experts to identify our ten features. A statistical analysis of this dataset is available in [?].

Initial prediction results

Fig. 1. ROC curve for the prediction of refrigerated vehicles ageing

Once the cleaned dataset obtained, a traditional classification workflow was applied: the data was split in a training (80%) and a testing set (20%). The objective was to sketch the construction of a first initial model, before any analysis of the dataset, using classical state-of-the-art methods. It was decided to build a first classification model using a decision tree [?], in order to obtain an interpretable model, that could easily be discussed with thermal engineers. To improve the results, a boosted version of the algorithm (see [?]) was used. The results were very encouraging, with a precision of 0.818 and a recall of 0.783. The F1 score was of 0.800. In addition, a ROC curve of this first classifier is presented on figure ??, also showing good performances for the ageing prediction.

With this first model available, it was possible to engage in a discussion with the experts in thermal engineering. The purpose was to understand what these result meant, but also and especially what could be done to improve the results, and what were the blocking points in the dataset itself. For example, some tuples might require additional cleaning, or some records in the database might cause problem for the learning process. As checking the data manually is very tiresome, even on a small dataset, it appeared that the notion of functional dependency could be extremely useful to assist the data expert in this specific task.

3 Domain experts and trust in the classification model

Preliminaries

We first recall basic notations and definitions that will be used throughout the paper. It is assumed the reader is familiar with databases notations (see [?]).

Let U be a set of attributes. A relation schema R is a name associated with attributes of U , i.e. R ⊆ U . A database schema R is a set of relation schemas.

Let D be a set of constants, A ∈ U and R a relation schema. The domain of A is denoted by dom(A) ⊆ D. A tuple t over R is a function from R to D. A relation r over R is a set of tuples over R. If X ⊆ U , and if t is a tuple over U , then we denote the restriction of t to X by t

[X]. If r is a relation over U , then r[X] = {t[X], t ∈ R}.
The active domain of A in r, denoted by ADOM (A, r), is the set of values taken by A in r. The active domain of r, denoted by ADOM (r), is the set of values in r.

We now define the syntax and the semantics of a FD.

if for all t 1 , t 2 ∈ r, if t 1 [X] = t 2 [X] then t 1 [C] = t 2 [C].
Without loss of generality, the scope is limited to crisp FDs, i.e. using only the strict equality. However, many other extensions have been proposed (see for example [?]). In addition, this paper only uses canonical FDs, that only have a unique attribute in their right hand side.

Strictly speaking, it is only possible for a relation to satisfy entirely a FD: otherwise, the dependency is not satisfied, there is no middle ground. When dealing with real life data, it is very likely that the FD will not be satisfied, even though a classification model might then be built with satisfying performances. However, understanding what tuples prevent the FD from being satisfied can then lead to improve the results, if the identified blockages can be explained and fixed by the domain experts. Such tuples are called counterexamples, and are defined as follows: Definition 3. Let r be a relation over R and X → Y a FD f on R. The set of counterexamples of f over r is denoted by CE(X → Y ) and defined as follows:

CE(X → Y, r) = {(t 1 , t 2 )|t 1 , t 2 ∈ r, t 1 [X] = t 2 [X] and t 1 [Y ] = t 2 [Y ]}
Counterexamples identify pairs of tuples for which the classifier will never be able to perform correctly, as for the same input, it will always predict the same output. These pairs are therefore very important, as their number directly impacts the quality of the classification. As a result, in order to evaluate the impact of counterexamples on classification, it is necessary to know their proportion in the dataset. Indeed, if a classifier only contains a few counterexamples, the impact on the classification will be marginal. On the opposite, a large counterexample set will significantly impact the accuracy results.

Evaluating the impact of counterexamples can be a little subtle. Indeed, a single tuple might cause many counterexamples, if it is in conflict with many other tuples that agree between them. On the opposite, on other relations, the counterexamples might be all due to many different tuples that each are in conflict with only a few other tuples. This problem is actually equivalent to estimating the error of the FD in a relation, a problem addressed in [?], in which three measures are presented, given a FD X → C and a relation r.

The first one, G 1 , gives the proportion of counterexamples in the relation:

G 1 (X → C, r) = |{(u, v)|u, v ∈ r, u[X] = v[X], u[C] = v[C]}| |r| 2
Following this first measure, it is also possible to determine the proportion of tuples involved in counterexamples. This measure G 2 is given as follows:

G 2 (X → C, r) = |{u|u ∈ r, ∃v ∈ r : u[X] = v[X], u[C] = v[C]}| |r|
These two metrics are designed to evaluate the importance of counterexamples in the relation. Similarly, measure G 3 computes the size of the set of tuples in r to obtain a maximal new relation s satisfying X → C. Contrary to [?] that present this measure as an error, we propose it as follows:

G 3 (X → C, r) = max({|s||s ⊆ r, s |= X → C}) |r|
In [?], it is underlined that G 3 is a direct upper bound for the accuracy of a classifier trained on the considered data, when the FD between the features and the class is considered, exactly as for the application to CEMAFROID's data.

Presentation of counterexamples

Using the tools presented before, the classification dataset was analyzed to discuss with the experts. A toy sample of counterexamples is presented in table ??. For sake of clarity, only five attributes are represented in this example. Each line represents a counterexample, which is two tuples. As they both share the same values over the classification features, only the ageing column, on which they differ, is represented for both(Ageing t 1 and Ageing t 2 ). This is also how the counterexamples were presented to the thermal engineers, using an interface developped to present the counterexample. It is named LeaFF (Learning Feasibility with FDs), and can be used to query the data used for prediction, retrieve the counterexample, and obtain the metrics for FD satisfaction. A snapshot of this interface is presented on figure ??, applied to CEMAFROID's data: it shows the part of the interface that can be used to enter the features and the class, so that the FD can be checked and counterexamples retrieved if necessary.

Measuring the counterexamples rate

The three aforementioned metrics were computed over the refrigerated vehicles dataset. The proportion of counterexamples, G 1 = 9.02%, is low, showing that the pairs of tuples in the dataset are not a big proportion. However, as G 2 = 100%, all tuples from the dataset are involved in at least one counterexamples: this is likely because a few tuples are in conflicts with almost all the other. This is confirmed by measuring G 3 = 86.73%: this shows that to obtain a counterexamples-free dataset, the vast majority of the data can be saved. When presented with the measures, the domain expert had many questions regarding what exactly each measure meant, and how to know whether the results were good or not: is it good if the score is low ? Or should it be higher to be better ? Indeed, these measures are not trivial, and the meaning they carry over the pairs of tuples is not intuitive right the first time. This interaction therefore highlighted that it will be interesting to find a convenient visualization for domain experts, to present this result in a more instinctive manner.

Explaining counterexamples

It then appeared necessary to dive into counterexamples. After a thorough discussion, it appeared that several factors could explain them, each having a different solution. Ultimately, these factors were divided into three main categories.

Dirty Data A considerable amount of time had been spent on preparing and cleaning the dataset in order to use it for classification. However, when looking at counterexamples, it appeared that some tuples contained data that appeared to be incorrect. For counterexample 1 in table ??, it appeared that the vehicle with a low ageing was actually a van instead of a truck. Similarly, for counterexample 2, the vehicle with a high ageing actually transported meat instead of vegetables. Such counterexamples are easy to fix by correcting the wrong values, once they have been detected using the FD-based approach. Alternatively, it is possible to take into account additional attributes that are more precise than the dirty ones: for example, the weight of the vehicle can better define the vehicle's type than the given label, so mistakes can be avoided if it is taken into account: with the weight, vans and trucks could be more easily differentiated.

Missing information

For other counterexamples, it appeared that the attributes selected for classification were not enough to explain their existence. However, other attributes, that had not been kept for classification, allowed to discriminate between the two tuples involved in the counterexample. For instance, in table ??, counterexample 3 can be removed if the number of food cases in the vehicle is considered. For counterexample 4, a specific characteristic of the cooling unit differed between the two tuples. As a result, taking those additional attributes, that at first had not been considered relevant for the classification, allowed to remove counterexamples, that will then improve the classifier's performances. This is a way to do feature engineering in collaboration with the domain experts.

Human Factor Finally, for a last group of counterexamples such as number 5 and number 6 from table ??, it appeared that the only explanation was a human factor, such as how the driver operates the vehicle. Indeed, this is susceptible of influencing the ageing of the vehicle, but it is hard to quantify, and may pose ethical issues. As a result, this last class of counterexamples is very difficult to fix, as data cannot be cleaned or completed. However, being aware that such counterexamples exist helps the data expert in understanding the limitations of the classification model. Finally, it also indicates other values that could be interesting to record: in this case for example the average speed of the vehicle. Similarly, during its life, the vehicle is subject to accidents of which nothing is known. Information about the nature and severity of such accidents could be useful for the study of ageing, and could also explain some counterexamples.

To assess the impact of these counterexamples on the predictive model, it was decided to remove the tuples that are the most involved in counterexamples from the dataset: each removed tuples was carefully checked with a thermic expert, and each removal allowed to gain accuracy for the classifier. It is necessary to be careful when removing such data to not create a biased model, but it can have a positive impact on the classifier's accuracy, directly linked to measure G 3 .

Take away lessons

Using functional dependencies to explore the classification dataset was an enriching experience, that created fruitful discussions and results. First, the counterexamples allowed to identify limitations in the dataset, and to take concrete actions to get higher quality data, and therefore improve the results for a future new model. The counterexamples are a powerful notion to avoid the domain expert from being overwhelmed by the data, as she then only have a small but meaningful subset of tuples to study. The counterexamples are therefore a perfect starting point for a discussion between data scientists and domain experts: while the first gain knowledge on data they are not expert on, the others can point out important information more easily. The counterexamples are a way for domain experts to read a concrete information that have an impact on their day-to-day work. By helping to clean and improve the dataset, domain experts stay in the loop, and better understand the data used in the learning process. Last but not least, they gain some evidence regarding whether or not it makes sense to infer a numerical model from their data. This study also shows that in classification, it is not possible to ignore the field reality, and to only see the problem as a matrix of data: the physical model is as important as the data itself, and bridges have to be built between physical and numerical models.

Conclusion

This paper presents the results obtained to better trust classification models in the context of a study with CEMAFROID, a french company delivering conformity attestations for refrigerated transport vehicles. To this end, a classification dataset was built and a first classifier was elaborated using standard classification methods. It showed very promising results, but also raised interrogations from the thermal engineers, related to trust issues in machine learning. In order to understand the dataset and to demystify the classifier, we proposed to see the classification model from the features to the class to be predicted as a functional dependency. The counterexamples to this FD then give direct limitations of the classifier. The counterexamples were analyzed, and various causes for their existence were discovered, as well as potential solutions to remove them. More importantly, domain experts were able to better understand the pros and cons of the numerical model, influencing their trust in the whole machine learning process. This study was therefore really enriching, allowing to bridge a gap by using FDs, a well-known notion in databases, into a machine learning process. The methodology from this paper could be used in any classification problem, to first study the existence of a model before trying to learn from data.

Definition 1 .Definition 2 .

 12 Let R be a relation schema, X ⊆ R and C ⊆ R\X. A FD on R is an expression of the form R : X → C (or simply X → C when R is clear from context) Let r be a relation over R and X → C a FD on R. X → C is satisfied in r, denoted by r |= X → C, if and only

Fig. 2 .

 2 Fig. 2. Snapshot of the interface LeaFF used to explore FDs and counterexamples

Table 1 .

 1 Subset of counterexamples from the classificationd dataset, on the ageing of refrigerated transport vehicles.

	id Manufac-	Cell	Insulation type Vehicle	Products Ageing	Ageing
	turer	Type		type		t1	t2
	1 Firm 1	Integrated Polyuréthane	Truck	Meat	High	Low
	2 Firm 2	Integrated Polyuréthane	Van	Fruits	High	Low
			with cylopentane
	3 Firm 3	Rapportee Polyuréthane	Panel	Frozen	High	Low
			with cylopentane	truck	food
	4 Firm 4	Integrated Polyuréthane	Trailer	Vegetables High	Low
			with cylopentane
	5 Firm 5	Rapportee Polyuréthane	Truck	Cheese	High	Low
			with cylopentane
			without CFC
	6 Firm 6	Rapportee Polyuréthane	Remorque Dairy	High	Low
			with cylopentane		products


Marcel F Hinss
email: marcel.hinss@isae-supaero.fremilie.jahanpour@isae-supaero.fr

Emilie Jahanpour

Anke Brock

Jean-Paul P Imbert

Raphaelle N Roy

Raphaelle Roy Long-Endurance

Long-endurance UAS

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

the perception of environmental elements and events with respect to time or space ( 5)

Top Down Attention

"Forgetting to check systems" " Not reacting to or not attending radio messages "

the voluntary allocation of attention to certain features, objects, or regions in space. [START_REF] Holtzer | Cognitive Fatigue Defined in 615 the Context of Attention Networks[END_REF] Vigilance decrement

"""

  Slugglishness after intense mission phases" temporary decrease in mental resources over time due to sustained cognitive effort (reaction time & accuracy, 4) Forgetting to check systems" "Not reacting to or not attending radio messages" Incorrect execution of a task not doing a task Cognitive Flexibility "Changes in mission objective occur as frequent as 2-3 times a week" "Not mentally prepared for the change in objective" "Difficulties with reprioritizing ." the ability to flexibly switch between tasks (2) Difficulties with reprioritizing ." "Not mentally prepared for the change in objective"


Andrew French
email: anfrench@hydrolab.arsusda.gov

Frederic Jacob

Thomas Schmugge

William Kustas

Comparing Surface Energy Flux Models using ASTER Imagery over Oklahoma

Surface energy flux estimates over central Oklahoma, during the summer of 2001, are derived in two different ways from thermal infrared and visible-near infrared ASTER (Advanced Spaceborne Thermal Emission and Reflection radiometer) 90 m resolution observations. In one approach, surface flux estimates are computed using a twosource energy balance (TSEB) model, which distinguishes between soil and vegetation flux components. The benefit of TSEB is an improved surface representation over sparsely vegetated terrain, as compared to one-layer models. In the other approach, surface flux estimates are computed from the Surface Energy Balance Algorithm for Land (SEBAL) model, which computes meteorological variables using information contained within the spatial variability of convective fluxes. A major benefit of the SEBAL model is that estimates can be obtained solely from remote sensing observations. Both models compare reasonably well with surface flux measurements, but their relative sensitivities and biases are different for the same input data. Sources of these modeling sensitivities and biases will be discussed.

I. INTRODUCTION

Modeling surface energy fluxes is a way to estimate spatial distributions of evapotranspiration (ET). Knowledge of ET is important for both hydrologists and climatologists, but retrieving accurate ET estimates is difficult. ET varies rapidly and is strongly dependent upon land surface heterogeneity. Remote sensing based estimates are the only practical way to retrieve spatial ET estimates, as they excel at representing surface heterogeneity. Using well-calibrated visible-near infrared (VNIR) observations, in conjunction with recently available multi-band thermal infrared data from the ASTER sensor, allows modeling the surface energy balance under a wide range of conditions, including sparse and stressed vegetation. However, existing remote sensing models vary considerably in their approach and assumptions. Some approaches augment satellite observations with surface observations, while others attempt to be self-contained. In this study, we model surface energy fluxes over a single region using two approaches representing each of these cases.

II. THE TSEB MODEL

The Two-Source Energy Balance (TSEB) [START_REF] Norman | A two-source approach for estimating soil and vegetation energy fluxes from observations of directional radiometric surface temperature[END_REF] model, a resistance network approach, can compute the four main surface energy flux components, sensible heat (H), latent heat (LE), soil heat (G), and net radiation (R n ), based upon separate contributions from soil and vegetation. The distinction between soil and vegetation is the prime characteristic of TSEB, and allows differences in radiative and aerodynamic properties of a heterogeneous surface to be accommodated. TSEB requires three remote sensing inputs: surface temperatures, vegetation indices and a land use classification. It also requires near surface meteorological observations of air temperature, humidity, wind speed and incoming solar radiation.

III. THE SEBAL MODEL

The Surface Energy Balance Algorithm for Land (SEBAL) [START_REF] Bastiaansen | A remote sensing surface energy balance algorithm for land (SEBAL)1. Formulation[END_REF], also a resistance approach, computes the surface flux components H, LE, G and R n almost entirely from remote sensing based observations of surface temperatures, vegetation indices and surface albedo. SEBAL accomplishes this by computing wind speed and air temperature, which are determined by semi-empirical relationships and simplifications of the energy balance over dry and wet areas. Subsequent computations produce the four surface fluxes from a single source at the land surface. Surface temperatures were obtained from 90 m ASTER thermal infrared observations in bands 10-14, and a temperature-emissivity separation algorithm [START_REF] Gillespie | A temperature and emissivity separation algorithm for Advanced Spaceborne Thermal Emission and Reflection Radiometer (ASTER) images[END_REF]. Correction of atmospheric effects used NCEP [START_REF]National Centers for Environmental Prediction[END_REF] profiles and MODTRAN simulations [START_REF] Berk | MODTRAN cloud and multiple scattering upgrade with applications to AVIRIS[END_REF]. Surface reflectance values, obtained from ASTER bands 1-8, were used to determine NDVI and albedo. They were computed at 90 m resolution by using the 6S model [START_REF] Vermote | Second Simulation of the Satellite Signal in the Solar Spectrum, 6S: an overview[END_REF] with the same NCEP profiles, plus observations provided by the Aeronet Project [START_REF]Southern Great Plains Site[END_REF]. Land use was determined from a supervised classification of 15 m resolution ASTER data (bands 1-3), which was subsequently resampled to match the 90 m surface temperature imagery.

Unstable aerodynamic conditions prevailed at the time of the satellite overpass. Radiometric temperatures over the grazing lands were ~36°C, while 2 m air temperature and southerly wind were ~29°C and 5 m s -1 (Table I). NDVI values ranged between 0.0 and 0.65, and indicated that grazing land vegetation LAI ranged between 1.0 and 3.0. The NDVI-surface temperature relationship was reasonable (Fig. 2), with complete cover showing low variability in temperature, while bare soil surfaces had high surface temperature variability. Both TSEB and SEBAL models returned surface energy flux components in close agreement with ground level observations at the E19 Bowen ratio site (Table II.). Means and standard deviations are based on nine 90 m pixels.

Net radiation (R n ) estimates were within 14 W m -2 of the observation at site E19. Although TSEB and SEBAL use the same value for both incoming solar and atmospheric radiation, they estimate R n in different ways. TSEB estimates R n from separate streams of visible and near infrared radiation, while SEBAL uses a one layer approach along with integrated values over the considered spectral ranges.

Soil flux (G) estimates from TSEB and SEBAL are identical, and exceed the E19 observation by 51 W m -2 . Agreement in G is coincidental. TSEB's G is estimated as a fraction (0.3) of net radiation at the soil level. SEBAL's G is estimated from an empirical formulation of heat transfer over bare soil and a vegetation extinction coefficient.

The most informative comparison between TSEB and SEBAL lies with the turbulent flux component, H. TSEB's H estimate is 18 W m -2 greater than SEBAL's and is within 3 W m -2 of the E19 observation. The observed wind speed, used by TSEB, and SEBAL's estimated wind speed values are similar (5.1 vs. 3.8 m s -1 ). Momentum roughness lengths are also similar (0.13 vs. 0.10 m). Therefore, the chief reason for differing H estimates is the surface air temperature gradient. TSEB assumes a spatially uniform air temperature at measurement height. SEBAL, on the other hand, spatially varies air temperature according to surface heterogeneities. In the current instance, TSEB appears to produce a slightly better H estimate, with half the variability of SEBAL's estimate.

The latent heat flux (LE) estimates show a similar relationship to the H estimates. Both TSEB and SEBAL LE fluxes are less than E19 observations by 35 and 20 W m -2 , respectively. The TSEB LE shows 1/3 the variability of the SEBAL LE, and results from using a constant near surface air temperature.

V. CONCLUSIONS

The comparison between two surface energy balance models using remote sensing data has just begun. Both the TSEB and the SEBAL approach produce estimates in close agreement with measurements from a single ground observation site. Future work will analyze imagery that includes multiple ground observation sites, for example in the Jornada Experimental Range in southern New Mexico.

Fig. 1 .

 1 Fig. 1. NDVI image over El Reno, Oklahoma extracted from ASTER scene, 10 June 2001. Light tones indicate high NDVI and thick vegetation, dark tones low NDVI and either bare soil or water bodies. The arrow points to the E19 flux station site. Image area is approximately 6x12km, with north towards the upper left direction IV. SURFACE FLUXES AT EL RENO, OKLAHOMAComparison between TSEB and SEBAL was performed on a 10 June 2001 ASTER scene over central Oklahoma, a portion of which is shown in Fig.1. The scene primarily includes grazing lands (light gray) and harvested winter wheat fields (dark gray). The box, pointed to by the arrow, indicates the location of the El Reno E19 Bowen Ratio site, which lies within the USDA El Reno Grazinglands Research center, an intensively studied site[START_REF] French | Estimating evapotranspiration over El Reno, Oklahoma with ASTER imaery[END_REF][START_REF] French | Estimating surface fluxes over the SGP site with remotely sensed data[END_REF][START_REF] Jackson | Soil moisture mapping at regional scales using microwave radiometry: the Southern Great Plains hydrology experiment[END_REF].

Fig. 2 .

 2 Fig. 2. Surface temperature vs. NDVI histogram over central Oklahoma from entire ASTER scene (60km x 60km) on 10 June 2001. Approximately 500,000 points are represented, with light tones indicating higher frequency and darker tones lower frequency.

Table II .

 II Surface Parameters & Fluxes, 10 June 2001 Means and Standard Deviations (W m -2 )


Patrice Cartraud
email: patrice.cartraud@ec-nantes.fr

Irina Ionescu
email: irina.ionescu@dartmouth.edu

Grégory Legrain
email: gregory.legrain@ec-nantes.fr

Nicolas Moës
email: nicolas.moes@ec-nantes.fr

Image-Based Computational Homogenization of Random Materials using Level Sets and X-FEM

Keywords: Homogenization, X-FEM, Level Sets, Digital Image

come   L'archive ouverte pluridisciplinaire

With the emergence of novel ways of characterizing material microstructures, there is a need to develop computational methods which have the capability to process these material data and solve models with a highly accurate representation of material morphology. Many approaches have been proposed for the computation of highly heterogeneous materials, which can be classified in two groups. In the first one, statistics are computed from the image for the reconstruction of a material microstructure model. Other methods make a direct use of a digital image, and the finite element method is applied most of the time to solve the boundary value problem. Many authors employ a voxel based mesh, which can be built automatically, but leads to a very large number of elements and to jagged edges. Another way to proceed is to capture geometrical information from the image and then generate a mesh. But this approach can be tedious for 3D complex microstructures. This paper presents the advantages of using a numerical method that couples the level set method with the extended finite element method (X-FEM), applied to solving problems of homogenization from a digital image representation of the microstructure. One of the key features of this method is the separation between the geometrical data, which are processed by the level set method and the mesh, which does not need to conform the microstructure geometry, thanks to the X-FEM method. The use of level sets techniques in the context of image segmentation leads to a precise representation of the geometry, the advantage of this technique being that changes in topology are handled implicitly. A user initialized contour is evolved based on image features such as grayscale intensity, gradient magnitude or image edges. The present application uses the Insight Toolkit (ITK) [START_REF] Ibanez | The ITK Software Guide[END_REF] for building the image segmentation application tailored to the specific needs of treating images of material microstructures. For each image the user has to specify the threshold of intensity values and an initial level set model. The level set solution is calculated to subpixel precision, and interpolated at pixel level. For a two phase material, the level set value corresponds to the distance to the material interface, with a positive or negative sign differenciating the phase.

Figure 1: Algorithm: the digital image is segmented using a level set threshold based segmentation filter and the X-FEM mesh is constructed incorporating the level set data in the enriched elements.

The X-FEM method is used to solve the mechanical problem on the microstructure. This formulation does not require a conforming mesh. Rather, a regular or structured mesh is constructed independent of the geometry and the physical boundaries are represented as the iso-zero of the level sets. The elements intersected by the material interface are enriched using a function which represents the strain jump at the interface. The capabilities of the coupling between the X-FEM and the level set method for micromechanics applications have been shown in [START_REF] Moës | A computational approach to handle complex microstructure geometries[END_REF], but the applications were restricted to microstructures with material interfaces that can be described by analytical level sets. This work advances the method one step further, presenting the process of obtaining the level set information corresponding to a digital image of a material structure and using it in setting up and solving an X-FEM problem, see Fig. 1. In this work, this numerical framework is used to obtain the overall elastic properties of heterogeneous materials, solving a homogenization problem posed on its microstructure. In order to illustrate the present approach, samples of heterogeneous materials with random microstructure are studied. Since the materials studied here can not be considered as periodic media, their effective properties are computed using an homogenization scheme with homogeneous kinematic boundary conditions. In addition to determining the effective properties of the structure, the question of the size of the representative volume element (RVE) arises. Following the method described in [START_REF] Kanit | Apparent and effective physical properties of heterogeneous materials: Representativity of samples of two materials from food industry[END_REF], subdivisions of the original sample are considered and the effective properties are determined for each subdivision. In summary, this study demonstrates the feasibility of using level sets and the X-FEM for treating problems of micromechanics. The method offers a direct way to treat problems of complex microstructures taking advantage of the versatility of level sets and the non-conforming meshing algorithm of X-FEM.


Ovidiu-Cristian Marcu
email: ovidiu-cristian.marcu@uni.lu

Pascal Bouvry
email: pascal.bouvry@uni.lu

In support of push-based streaming for the computing continuum

Keywords: Streaming, Real-time storage, Push-based, Pull-based, Locality

Real-time data architectures are core tools for implementing the edge-to-cloud computing continuum since streams are a natural abstraction for representing and predicting the needs of such applications. Over the past decade, Big Data architectures evolved into specialized layers for handling real-time storage and stream processing. Open-source streaming architectures efficiently decouple fast storage and processing engines by implementing stream reads through a pull-based interface exposed by storage. However, how much data the stream source operators have to pull from storage continuously and how often to issue pull-based requests are configurations left to the application and can result in increased system resources and overall reduced application performance. To tackle these issues, this paper proposes a unified streaming architecture that integrates co-located fast storage and streaming engines through push-based source integrations, making the data available for processing as soon as storage has them. We empirically evaluate pull-based versus push-based design alternatives of the streaming source reader and discuss the advantages of both approaches.

Introduction

The edge-to-cloud computing continuum [START_REF] Antoniu | Towards Integrated Hardware/Software Ecosystems for the Edge-Cloud-HPC Continuum[END_REF] implements fast data storage and streaming layered architectures that are deployed intensively in both Cloud [START_REF] Akidau | The dataflow model: A practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing[END_REF] and Fog architectures [START_REF] Nguyen | A low-cost two-tier fog computing testbed for streaming iot-based applications[END_REF]. Fast data processing enables high-throughput data access to streams of logs, e.g., daily processing terabytes of logs from tens of billions of events at CERN accelerator logging service [START_REF]Next CERN Accelerator Logging Service Architecture[END_REF]. Moreover, implementing sensitive information detection with the NVIDIA Morpheus AI framework enables cybersecurity developers to create optimized AI pipelines for filtering and processing large volumes of real-time data [START_REF]Sensitive information detection using the NVIDIA Morpheus AI framework[END_REF].

Over the past decade, Big Data architectures evolved into specialized layers for handling real-time storage and stream processing. To efficiently decouple fast storage and streaming engines, architects design a streaming source interface that implements data stream reads through pull-based remote procedure calls (RPC) APIs exposed by storage. The streaming source operator continuously pulls data from storage while its configuration (i.e., how much data to pull and how often to issue pull requests) is left to the application, being a source of bottlenecks and overall reduced application performance. In turn, decoupled streaming sources help manage backpressure [START_REF] Kalavri | Three steps is all you need: Fast, accurate, automatic scaling decisions for distributed streaming dataflows[END_REF] and simplifies fault-tolerance implementation for system crash management.

The pull-based integration approach is opposed to monolithic architectures [START_REF] Zou | Pangea: Monolithic distributed storage for data analytics[END_REF] that have the opportunity to more efficiently and safely optimize datarelated tasks. Another architectural choice is to closely integrate fast storage and streaming engines through push-based data sources, making the data available to the processing engine as soon as it is available. The push-based source integration approach should keep control of the data flow to ensure backpressure and should promote an easy integration through storage and processing non-intrusive extensions to further promote open-source real-time storage and streaming development.

Our challenge is then how to design and implement a push-based streaming source strategy to efficiently and functionally integrate realtime storage and streaming engines while keeping the advantages of a pullbased approach. Towards this goal, this paper introduces a push-based streaming design to integrate co-located real-time storage and processing engines. We implement pull-based and push-based stream sources as integration between open-source KerA1 , a real-time storage system, and Apache Flink [3], a stream processing engine. We empirically evaluate the KerA-Flink push-based and pullbased approaches and we show that the push-based approach can be competitive with a pull-based design while requiring reduced system resources. Furthermore, when storage resources are constrained, the push-based approach can be up to 2x more performant compared to a pull-based design.

Background and Related Work

Decoupling producers and consumers through message brokers (e.g., Apache Kafka [START_REF] Jay | Kafka: A distributed messaging system for log processing[END_REF]) can help applications through simplified real-time architectures. This locality-poor design is preferred over monolithic architectures by state-of-theart open-source streaming architectures. Big Data frameworks that implement MapReduce [START_REF] Dean | Mapreduce: Simplified data processing on large clusters[END_REF] are known to implement data locality (pull-based) optimizations. General Big Data architectures can thus efficiently co-locate map and reduce tasks with input data, effectively reducing the network overhead and thus increasing application throughput. However, they are not optimized for lowlatency streaming scenarios. User-level thread implementations such as Arachne [START_REF] Qin | Arachne: Core-aware thread management[END_REF] and core-aware scheduling techniques like Shenango, Caladan [START_REF] Ousterhout | Shenango: Achieving high cpu efficiency for latency-sensitive datacenter workloads[END_REF][START_REF] Fried | Caladan: Mitigating Interference at Microsecond Timescales[END_REF] can further optimize co-located latency-sensitive stream storage and analytics systems, but are difficult to implement in practice.

Finally, it is well known that message brokers, e.g., Apache Kafka [START_REF] Jay | Kafka: A distributed messaging system for log processing[END_REF][START_REF] Kafka | [END_REF], Apache Pulsar [5], Distributedlog [START_REF] Sijie | Distributedlog: A high performance replicated log service[END_REF], Pravega [8], or KerA [START_REF] Marcu | Kera: Scalable data ingestion for stream processing[END_REF], can contribute to higher latencies in streaming pipelines [START_REF] Javed | Characterization of big data stream processing pipeline: A case study using flink and kafka[END_REF]. Indeed, none of these open-source storage systems implement locality and thus force streaming engines to rely on a pull-based implementation approach for consuming data streams. Consistent state management in stream processing engines is difficult [START_REF] Carbone | State management in apache flink®: Consistent stateful distributed stream processing[END_REF] and depends on real-time storage brokers to provide indexed, durable dataflow sources. Therefore, stream source design is critical to the fault-tolerant streaming pipeline and potentially a performance issue.

A pull-based source reader works as follows: it waits no more than a specific timeout before issuing RPCs to pull (up to a particular batch size) more messages from stream storage. One crucial question is how much data these sources have to pull from storage brokers and how often these pull-based RPCs should be issued to respond to various application requirements. Consequently, a push-based approach can better solve these issues by pushing the following available messages to the streaming source as soon as more stream messages are available. However, a push-based source reader is more difficult to design since coupling storage brokers and processing engines can bring back issues solved by the pull-based approach (e.g., backpressure, scalability). Thus, we want to explore a non-monolithic design that integrates real-time storage and streaming engines through a push-based stream source approach and understand the performance advantages (e.g., throughput) of both approaches. Towards this goal let us introduce next a push-based streaming design that unifies real-time storage and processing engines and describe our implementation.

3 Unified Real-time Storage and Processing Architecture:

Our Push-based Design and Implementation

Background. Fast storage (e.g., [START_REF] Marcu | Kera: Scalable data ingestion for stream processing[END_REF][START_REF] Marcu | Virtual log-structured storage for high-performance streaming[END_REF]) implements a layer of brokers to serve producers and consumers of data streams. As illustrated in Figure 1, a multithreaded broker is configured with one dispatcher thread polling the network and responsible for serving read/write RPC requests and multiple working threads that do the actual writes and reads. Streaming engines [START_REF] Venkataraman | Drizzle: Fast and Adaptable Stream Processing at Scale[END_REF][START_REF] Miao | Streambox: Modern Stream Processing on a Multicore Machine[END_REF]3] implement a layer of workers. E.g., in Apache Flink, each worker implements a JVM process that can host multiple slots (a slot can have one core). Sources and other operators are deployed on worker slots ([3, 6]) and are configured to use in-memory buffers. Backpressure is ensured as follows: sources continuously issue pull-based read requests as long as buffers are not filled.

Design principles. To ensure backpressure, our push-based design takes source buffers outside the processing engine and shares buffer control with storage and processing through pointers and notifications. To avoid network overhead, we propose to co-locate real-time storage and streaming engines. To remove storage interference of read and write RPC requests, we separate reads and writes through dedicated push worker threads. The push-based mechanism completely removes the RPC and networking overheads of the pull-based approach. Push-based architectural design. As illustrated in Figure 1, we co-locate a storage broker and one or multiple processing workers on a multi-core node. We propose to leverage a shared partitioned in-memory buffer between (push-based) streaming sources and storage brokers to provide backpressure support to streaming engines and to allow for transparent integration with various streaming storage and processing engines. Multiple sources coordinate to launch only one pushbased RPC request (step 1). Storage creates (once) a dedicated worker thread (in black) that is responsible to continuously fill shared reusable objects with next stream data (step 2). Source tasks are notified when objects have new updates (step 3) and then process these data. The worker thread is notified (step 4) when an object was consumed, so it can reuse it an refill with new data. This flow (steps 2-4) executes continuously. Objects have a fixed-size and are shared through pointers by worker thread and source tasks. The source creates tuples and pushes them further to the stream processing operator tasks. Backpressure is ensured through shared store notifications.

Implementation . On the same node live three processes: the streaming broker, the processing worker and the shared partitioned object store. As illustrated in Figure 1, two push-based streaming source tasks are scheduled on one process-ing worker. At execution time, only one of the two sources will issue (once!) the push-based RPC (e.g., based on the smallest of the source tasks' identifiers). This special RPC request (implemented by storage) contains initial partition offsets (partitioned streams) used by sources to consume the next stream records.

The storage handles the push-based RPC request by assigning a worker thread responsible for creating and pushing the next chunks of data associated with consumers' partition offsets. We implement the shared-memory object store based on Apache Arrow Plasma, a framework that allows the creation of in-memory buffers (named objects) and their manipulation through shared pointers. Our push-based RPC is implemented on the KerA storage engine while we transparently integrate our KerA connector with Apache Flink for stream processing.

Evaluation

Our goal is to understand the performance advantages of push-based and pullbased streaming source integrations between real-time storage and streaming engines. While the pull-based approach simplifies implementation, the pushbased approach requires a more tight integration. What performance benefits characterize each approach?

Experimental Setup and Parameter Configuration. We run our experiments on the Aion cluster2 by deploying Singularity containers (for reproducibility) over Aion regular nodes through Slurm jobs. One Aion node has two AMD Epyc ROME 7H12 CPUs (128 cores), each with 256 GB of RAM, interconnected through Infiniband 100Gb/s network. Producers are deployed separately from the streaming architecture. The KerA broker is configured with up to 16 worker cores (for pull-based, while the push-based approach uses only one dedicated worker core) while the partition's segment size is fixed to 8 MiB. We use Apache Flink version 1.13.2. We configure several producers Np (respectively consumers Nc, values=1,2,4,8), similarly to [START_REF] Marcu | Virtual log-structured storage for high-performance streaming[END_REF], that send data chunks to a partitioned stream having Ns partitions. Each partition is consumed exclusively by its associated consumer. Producers concurrently push synchronous RPCs having one chunk of CS size (values=1,2,4,8,16,32,64,128 KiB) for each partition of a broker, having in total ReqS size. Each chunk can contain multiple records of configurable RecS size for the synthetic workloads. We configure producers to read and ingest Wikipedia files in chunks having records of 2 KiB. Flink workers correspond to the number of Flink slots NFs (values=8,16) and are installed on the same Singularity instance where the broker lives.

To understand previous parameters' impact on performance, we run each experiment for 60 to 180 seconds while we collect producer and consumer throughput metrics (records every second). We plot 50-percentile cluster throughput per second for each experiment (i.e., by aggregating the write/read throughput of each producer/consumer every second), and we compare various configurations. Benchmarks. The first benchmark (relevant to use cases that transfer or duplicate partitioned datasets) implements a simple pass-over data, iterating over each record of partitions' chunks while counting the number of records. The second benchmark implements a filter function over each record, being a representative workload used in several real-life applications (e.g. indexing the monitoring data at the LHC [START_REF] Large | [END_REF]). The next benchmarks (CPU intensive) implement word count over Wikipedia datasets. For reproducibility, our benchmark code is open-source and a technical report [START_REF] Marcu | Colocating real-time storage and processing: An analysis of pull-based versus push-based streaming[END_REF] further describes these applications.

Results and Discussion

Synthetic benchmarks: the count operator. In our first evaluation, we want to understand how our chosen parameters can impact the aggregated throughput while ingesting through several concurrent producers. As illustrated in Figure 2, we experiment with two, four, and eight concurrent producers. Increasing the chunk size CS, the request size ReqS increases proportionally, for a fixed record size RecS of fixed value of 100 Bytes. While increasing the chunk size, we observe (as expected) that the cluster throughput increases; having more producers helps, although they compete at append time. We also observe that replication considerably impacts cluster throughput (as expected) since each producer has to wait for an additional replication RPC done at the broker side. Producers wait up to one millisecond before sealing chunks ready to be pushed to the broker (or the chunk gets filled and sealed) -this configuration can help tradeoff throughput with latency. With only two producers, we can obtain a cluster throughput of ten million records per second, while we need eight producers to double this throughput. Next experiments introduce concurrent consumers in parallel with concurrent producers.

The subsequent evaluation looks at concurrently running producers and consumers and compares pull-based versus push-based consumers. The broker is configured with 16 working cores to accommodate up to eight producers and eight consumers concurrently writing and reading chunks of data. Since consumers compete with producers, we expect the producers' cluster throughput to drop compared to the previous evaluation that runs only concurrent producers. This is shown in Figure 3: due to higher competition to broker resources by consumers, producers obtain a reduced cluster throughput compared to the previous experiment. We observe that consumers fail to keep up with the producers' rate.

These experiments illustrates the impact on performance of the interference between reads and writes. Increasing the chunk size, we observe that pull-based consumers obtain better performance than push-based. Increasing the number of consumers, we observe that the dedicated thread does not keep up with more than four consumers; otherwise, push-based is competitive with pull-based or slightly better. However, (although with eight consumers the pull-based strategy can obtain a better cluster throughput,) for up to four consumers the push-based strategy not only can obtain slightly better cluster throughput but the number of resources dedicated to consumers reduces considerably (two threads versus eight threads for the configuration with four consumers). While pull-based consumers double the cluster throughput when using 16 threads for the source operators, push-based consumers only use two threads for the source operator.

Synthetic Benchmarks: The Filter Operator. We further compare pull-based versus push-based consumers when implementing the filter operator, in addition, to counting for a stream with eight partitions. Similar to previous experiments, the push-based consumers are slower when scaled to eight for larger chunks, as illustrated in Figure 4. As illustrated in Figure 5, when experimenting with up to four producers and four consumers over a stream with four partitions, the push-based strategy provides a cluster throughput slightly higher with smaller chunks, being able to process two million tuples per second additionally over the pull-based approach. With larger chunks, the throughput reduces: architects have to carefully tune the chunk size in order to get the best performance. When experimenting with smaller chunks, more work needs to be done by pull-based consumers since they have to issue more frequently RPCs (see Figure 7). Moreover, the push-based strategy provides higher or similar cluster throughput than the pull-based strategy while using fewer resources.

Next, we design an experiment with constrained resources for the storage and backup brokers configured with four cores. We ingest data from four producers into a replicated stream (factor two) with eight partitions. We concurrently run four consumers configured to use Flink-based push and pull strategies and native C++ pull-based consumers. Consumers iterate, filter and count tuples that are reported every second by eight Flink mappers. We report our results in Figure 6 where we compare the cluster throughput of both producers and consumers. Producers compete directly with pull-based consumers, and we expect the cluster throughput to be higher when concurrent consumers use a push-based strategy. However, producers' results are similar except for the 32 KB chunk size when producers manage to push more data since pull-based consumers are slower. We observe that the C++ pull-based consumers can better keep up with producers while push-based consumers can keep up with producers when configured to use smaller chunks. The push-based strategy for Flink is up to 2x better than the pull-based strategy of Flink consumers. Consequently, the push-based approach can be more performant for resource-constrained scenarios.

Wikipedia Benchmarks: (Windowed) Word Count Streaming. For the following experiments, the producers are configured to read Wikipedia files in chunks with records of 2 KiB. Therefore, producers can push about 2 GiB of text in a few seconds. Consumers run for tens of seconds and do not compete with producers. As illustrated in Figure 8, pull-based and push-based consumers demonstrate similar performance. We plot word count tuples per second aggregated for eight mappers while scaling consumers from one to four. Results are similar when we experiment with smaller chunks or streams with more partitions since this benchmark is CPU-bound. To avoid network bottlenecks when processing large datasets like this one (e.g., tens of GBs) on commodity clusters, the push-based approach can be more competitive when pushing pre-processing and local aggregations at the storage. Discussion and Future Implementation Optimizations. Regarding our prototype implementation, we believe there is room for further improvements. One future step is integrating the shared object store and notifications mechanism inside the broker storage implementation. This choice will bring up two potential optimizations. Firstly, it would avoid another copy of data by leveraging existing in-memory segments that store partition data (necessary for high-throughput use cases). Secondly, we could optimize latency by implementing the notification mechanism through the asynchronous RPCs available in KerA. Furthermore, implementing pre-processing functions in-storage (e.g., as done in [START_REF] Bhardwaj | Adaptive placement for in-memory storage functions[END_REF]) can further improve performance by reducing data movement.

Conclusion

We have proposed a unified real-time storage and processing architecture that leverages a push-based strategy for streaming consumers. Experimental evalua-tions show that when storage resources are enough for concurrent producers and consumers, the push-based approach is performance competitive with the pullbased one (as currently implemented in state-of-the-art real-time architectures) while consuming fewer resources. However, when the competition of concurrent producers and consumers intensifies and the storage resources (i.e., number of cores) are more constrained, the push-based strategy can enable a better throughput by a factor of up to 2x while reducing processing latency.

Fig. 1 .

 1 Fig.1. Unified real-time storage and stream processing architecture. Storage broker and processing worker are co-located on a multi-core node while stream source operators implement push-based consumers through shared memory partitioned object store. At runtime, source tasks consume data from shared reusable memory objects filled by storage as data arrives.

Fig. 2 .

 2 Fig. 2. Impact of replication and chunk size on ingestion cluster throughput (only producers). Parameters: Np = 2,4,8, RecS = 100 Bytes, one stream with Ns = 8 partitions. R1 Prods2 represents replication factor one and two concurrent producers writing to one stream. R2 Prods8 represents replication factor two and eight producers. Results are similar for a stream with Ns = 16.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Only producers (top). Pull-based (left) versus push-based (right) consumers for iterate and count benchmark for a stream with Ns = 8. Parameters: Np = Nc = 2,4,8, replication R = 1,2, consumer CS = 128 KiB, we plot producer CS = 8,16,32,64.

Fig. 5 .

 5 Fig. 5. Only producers (top). Pull-based (left) versus push-based (right) consumers for iterate, count and filter benchmark for a stream with 4 partitions.

Fig. 6 .

 6 Fig.6. Iterate, count and filter benchmark constrained broker resources. Comparing C++ pull-based consumers with Flink pull-based and push-based consumers. Prods-Push corresponds to producers running concurrently with push-based Flink consumers i.e. ConsPush. ProdsPullF corresponds to producers running concurrently with pullbased Flink consumers i.e. ConsPullF. ProdsPullZ corresponds to producers running concurrently with C++ pull-based consumers. Four producers and four consumers ingest and process a replicated stream (factor two) with eight partitions over one broker storage with four working cores. Consumer chunk size equals the producer chunk size.

Fig. 8 .

 8 Fig. 8. Pull-based consumers versus push-based consumers for the word count benchmarks with 4 partitions. The left figure presents the word count benchmarks, the right figure corresponds to the windowed word count benchmark. FLCons2 represents two push-based consumers while FPLCons4 represents four pull-based consumers.

  Iterate and count benchmark stream with 8 partitions broker with 8 cores. Evaluation of pull-based and push-based Flink consumers. ProdsPush corresponds to producers running concurrently with push-based Flink consumers i.e. ConsPush. Prod-sPullF corresponds to producers running concurrently with pull-based Flink consumers i.e. ConsPullF. Consumer chunk size equals the producer chunk size multiplied by 8. We plot producer chunk size.

						ProdsPush2
						ProdsPush4
						ProdsPullF2
						ProdsPullF4
						ConsPush2
						ConsPush4
						ConsPullF2
						ConsPullF4
						Chunk Size (KB)
	Fig. 7. 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 3 2.8 Cluster Throughput (M. records/s)	128	FL_Cons1 FL_Cons2 FL_Cons4 FPL_Cons1 Chunk Size (KB) FPL_Cons2 FPL_Cons4	Cluster Throughput (M. records/s)	0 0.2 0.4 0.6 0.8 1	128	Chunk Size (KB) FL_Cons1 FL_Cons2 FL_Cons4 FPL_Cons1 FPL_Cons2 FPL_Cons4

KerA-Flink integration source code: https://gitlab.uni.lu/omarcu/zettastreams.

more details at https://hpc.uni.lu/infrastructure/supercomputers the Aion section

Acknowledgment

The experiments presented in this paper were carried out using the HPC facilities of the University of Luxembourg [26] -see hpc.uni.lu. This work is partially funded by the SnT-LuxProvide partnership on bridging clouds and supercomputers and by the Fonds National de la Recherche Luxembourg (FNR) POLLUX program under the SERENITY Project (ref. C22/IS/17395419).