Corentin Kervadec
email: corentin.kervadec@orange.com

Valentin Vielzeuf
email: valentin.vielzeuf@orange.com

Stéphane Pateux
email: stephane.pateux@orange.com

Alexis Lechervy
email: alexis.lechervy@unicaen.fr

Frédéric Jurie
email: frederic.jurie@unicaen.fr

CAKE: Compact and Accurate K-dimensional representation of Emotion

come   L'archive ouverte pluridisciplinaire

Introduction

Facial expression is one of the most used human means of communication after language. Thus, the automated recognition of facial expressions -such as emotions -has a key role in affective computing, and its development could benefit human-machine interactions.

Different models are used to represent human emotion states. Ekman et al. [START_REF] Ekman | Constants across cultures in the face and emotion[END_REF] propose to classify the human facial expression resulting from an emotion into six classes (resp. happiness, sadness, anger, disgust, surprise and fear) supposed to be independent across the cultures. This model has the benefit of simplicity but could be not sufficient to address the c 2018. The copyright of this document resides with its authors. It may be distributed unchanged freely in print or electronic forms. Representation Size AffectNet Validation Accuracy (%) Figure 2: Influence of adding supplementary dimensions to arousal-valence when predicting emotion on AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF]. whole complexity of human affect. Moreover it suffers from serious intra-class variations as, for instance, soft smile and laughing equally belong to happiness. That is why Ekman's emotion classes are sometimes assembled into compound emotions [START_REF] Du | Compound facial expressions of emotion[END_REF] (e.g. happily surprised). Others have chosen to represent emotion with an n-dimensional continuous space, as opposite to the Ekman's discrete classes. Russel has built the Circumplex Model of Affect [START_REF] James | A circumplex model of affect[END_REF] in which emotion states are described by two values: arousal and valence. Arousal represents the excitation rate -the higher the arousal is, the more intense the emotion isand valence defines whether the emotion has a positive or a negative impact on the subject. Russels suggests in [START_REF] James | A circumplex model of affect[END_REF] that all Ekman's emotions [START_REF] Ekman | Constants across cultures in the face and emotion[END_REF] and compound emotions could be mapped in the circumplex model of affect. Furthermore, this two-dimensional approach allows a more accurate specification of the emotional state, especially by taking its intensity into account.

A third dimension has been added by Mehrabian et al. [START_REF] Mehrabian | Pleasure-arousal-dominance: A general framework for describing and measuring individual differences in temperament[END_REF] -the dominance -which depends on the degree of control exerted by a stimulus. Last, Ekman and Friesen [START_REF] Ekman | Measuring facial movement[END_REF] have come up with the Facial Action Code System (FACS) using anatomically based action units. Developed for measuring facial movements, FACS is well suited for classifying facial expressions resulting from an affect.

Based on these emotion representations, several large databases of face images have been collected and annotated according to emotion. EmotioNet [START_REF] Benitez-Quiroz | Emotionet: An accurate, real-time algorithm for the automatic annotation of a million facial expressions in the wild[END_REF] gathers faces annotated with Action Units [START_REF] Ekman | Measuring facial movement[END_REF]; SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF], FER-13 [START_REF] Goodfellow | Challenges in representation learning: A report on three machine learning contests[END_REF] and RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] propose images in the wild annotated in basic emotions; AffecNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF] is a database annotated in both discrete emotion [START_REF] Ekman | Constants across cultures in the face and emotion[END_REF] and arousal-valence [START_REF] James | A circumplex model of affect[END_REF].

The emergence of these large databases has allowed to develop automatic emotion recognition systems, such as the recent approaches based on Deep Neural Networks (DNN). Af-fectNet's authors [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF] use three AlexNet [START_REF] Krizhevsky | Imagenet classification with deep convolutional neural networks[END_REF] to learn respectively emotion classes, arousal and valence. In [START_REF] Ng | Deep learning for emotion recognition on small datasets using transfer learning[END_REF], the authors make use of transfer learning to counteract the smallness of the SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] dataset, by pre-training their model on ImageNet [START_REF] Deng | Imagenet: A large-scale hierarchical image database[END_REF] and FER [START_REF] Goodfellow | Challenges in representation learning: A report on three machine learning contests[END_REF]. In [START_REF] Acharya | Covariance pooling for facial expression recognition[END_REF] authors implement Covariance Pooling using second order statistics when training on emotion recognition (on RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] and SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF]).

Emotion labels, FACS and continuous representations have their own benefits -simplic-ity of the emotion classes, accuracy of the arousal-valence, objectivity of the FACS, etc.but also their own drawbacks -imprecision, complexity, ambiguity, etc. Therefore several authors have tried to leverage the benefits of all these representations. Khorrami et al. [START_REF] Khorrami | Do deep neural networks learn facial action units when doing expression recognition[END_REF] first showed that neural networks trained for expression recognition implicitly learn facial action units. Contributing to highlighting the close relation between emotion and Action Units, Pons et al. [START_REF] Pons | Multi-task, multi-label and multi-domain learning with residual convolutional networks for emotion recognition[END_REF] learned a multitask and multi-domain ResNet [START_REF] He | Deep residual learning for image recognition[END_REF] on both discrete emotion classes (SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF]) and Action Units (EmotioNet [START_REF] Benitez-Quiroz | Emotionet: An accurate, real-time algorithm for the automatic annotation of a million facial expressions in the wild[END_REF]). Finally, Li et al. [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] proposed a "Deep Locality-Preserving Learning" to handle the variability inside an emotion class, by making classes as compact as possible.

In this context, this paper focuses on the links between arousal-valence and discrete emotion representations for image-based emotion recognition. More specifically, the paper proposes a methodology for learning very compact embedding, with not more than 3 dimensions, performing very well on emotion classification task, making the visualization of emotions easy, and bearing similarity with the arousal-valence representation.

2 Learning Very Compact Emotion Embeddings

Some Intuitions About Emotion Representations

We first want to experimentally measure the dependence between emotion and arousalvalence as yielded in [START_REF] James | A circumplex model of affect[END_REF]. We thus display each sample of the AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF] validation subset in the arousal-valence space and color them according to their emotion label (Figure 1). For instance, a face image labelled as neutral with an arousal and a valence of zero is located at the center of Figure 1 and colored in blue. It clearly appears that a strong dependence exists between discrete emotion classes and arousal-valence. Obviously, it is due in part to the annotations of the AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF] dataset, as the arousal-valence have been constrained to lie in a predefined confidence area based on the emotion annotation. Nevertheless, this dependence agrees with the Circumplex Model of Affect [START_REF] James | A circumplex model of affect[END_REF].

To evaluate further how arousal-valence representation is linked to emotion labels, we train a classifier made of one fully connected layer1 (fc-layer) to infer emotion classes from arousal-valence values provided by AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF] dataset. We obtain the accuracy of 83%, confirming that arousal-valence can be an excellent 2-d compact emotion representation.

This raises the question of the optimality of this 2-d representation. Would adding a third dimension to arousal-valence make the classification performance better? To address this question, we used the 512-d hidden representation of a ResNet-18 [START_REF] He | Deep residual learning for image recognition[END_REF] trained to predict discrete emotions on the AffectNet dataset [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF]. This representation is then projected into a more compact space using a fc-layer outputting k dimensions, which are concatenated with the arousal-valence values. On top of this representation, we add another fc-layer predicting emotion classes. The two fc-layers are finally trained using Adam optimizer [START_REF] Diederik | Adam: Amethod for stochastic optimization[END_REF]. Adding 1 dimension to arousal-valence gives a gain of +3 points on the accuracy. It agrees with the assumption that a three-dimensional representation is more meaningful than a two-dimensional one [START_REF] Mehrabian | Pleasure-arousal-dominance: A general framework for describing and measuring individual differences in temperament[END_REF]. The benefit of adding more than 1 dimension is exponentially decreasing; with +512 dimensions, the gain is only of +0.6 points compared to adding 1 dimension, as shown in Figure 2.

From these observations, the use of a compact representation seems to be consistent with discrete emotion classes, as it enables an accuracy of 83% and 86% -respectively for a 2-d and a 3-d representation -and it even may allow to describe affect states with more contrast and accuracy. Even if arousal-valence is a good representation for emotion recognition, the question of its optimality has not been answered by these preliminary experiments. In other words, is it possible to learn 2-d (or 3-d) embedding better than those built on arousalvalence? We positively answer this question in Section 2.2.

Learning Compact and Accurate Representations of Emotions

Based on the previous observations, this section proposes a methodology for learning a compact embedding for emotion recognition from images.

Features extraction

The basic input of our model is an image containing one face displaying a given emotion. We first extract 512-d features specialized in emotion recognition. So as to, we detect the face, align its landmarks by applying an affine transform and crop the face region. The so-obtained face is then resized into 224 × 224 and fed to a ResNet-18 [START_REF] He | Deep residual learning for image recognition[END_REF] network (Figure 3, Features extraction). The face image is augmented (e.g. jittering, rotation), mostly to take the face detector noise into account. We also use cutout [START_REF] Devries | Improved regularization of convolutional neural networks with cutout[END_REF] -consisting in randomly cutting a 45 × 45 pixels sized patch from the image -to regularize and improve the robustness of our model to facial occlusions. Our ResNet outputs 512-d features, on top of which a fc-layer can be added. At training time, we also use dropout [START_REF] Srivastava | Dropout: a simple way to prevent neural networks from overfitting[END_REF] regularization. The neural network can be learned from scratch on two given tasks: discrete emotion classification or arousal-valence regression. In the same fashion we can train the ResNet-18 using arousal-valence regression. In this case, the so-obtained arousal-valence regressor can be used to infer arousal-valence values from novel images and concatenate them to the k features of the embedding. Thus we reproduce here the exact experiment done in Section 2.1 in order to assess the benefit of a third (or more) dimension. The difference is that arousal-valence are not ground truth values but predicted ones. These methods are denoted as AV1, AV2, AV3, etc. for the different values of k.

Compact emotion encoding

Domain independent embedding

As we want to ensure a generic compact enough representation, independent of the datasets, we learn the previously described model jointly on several datasets, without any further fine-tuning.

Our corpus is composed of AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF], RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] and SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF], labelled with seven discrete emotion classes: neutral, happiness, sad, surprise, fear, disgust and anger. Our training subset is composed of those of AffectNet (283901 elts., 95.9% of total), RAF (11271 elts., 3.81% of total) and SFEW (871 elts., 0.29% of total). Our testing subset is composed of the subsets commonly used for evaluation in the literature (validation of SFEW and Af-fecNet, test of RAF).

To ease the multi-domain training, we first pre-train our features extractor model on AffectNet and freeze its weights. Then we apply the same architectures as described before, but duplicate the last fc-layer in charge of emotion classification in three dataset-specific layers (Figure 3, multi-domain learning). The whole model loss is a modified softmax cross entropy defined as follows:

Loss = 1 N N ∑ i=1 3 ∑ j=1 w i, j class w j dataset E(y i , ŷi, j ) (1)
where j is ranging in [AffectNet, RAF, SFEW], y i is the label of i th element, ŷi, j is the prediction of the j th classifier on the i th element, E is the softmax cross entropy loss, N is the number of elements in the batch, w i class is a weight given to the i th element of the batch depending on its emotion class and w j dataset is a weight given to the j th classifier prediction. Each sample of the multi-domain dataset is identified according to its original database, allowing to choose the correct classifier's output when computing the softmax cross entropy.

The w class weight is defined as:

w i, j class = N j total N i, j class ×nbclass
where N j total is the number of elements in the j th dataset, N i, j class is the number of elements in the class of the i th element of the j th dataset and nbclass is the number of classes (7 in our case). The goal here is to fix the important class imbalance in the dataset by forcing to fit the uniform distribution, as previously done by [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF].

The w dataset weight permits to take the imbalance between dataset's sizes into account.

w j dataset = 1 log N j total sample ∈ j th dataset 0 sample / ∈ j th dataset (2)
We thus define a global loss enabling to optimize the last two layers of our model (namely Emotion Encoding and Multi-domain Learning in Figure 3) on the three datasets at the same time. The dimension k (or k + 2 in the case of the arousal-valence approach) can easily be changed and help to evaluate the interest of supplementary dimensions for emotion representation.

Experiments

Evaluation Metrics

We measure the classification performance with the accuracy and the macro F1 Score (3). Accuracy measures the number of correctly classified samples. Instead of accuracy, we prefer macro F1 score which gives the same importance to each class:

F 1macro = 1 N c N c ∑ i F 1i F 1i = 2 prec i • rec i prec i + rec i prec i = t p i t p i + f p i rec i = t p i t p i + f n i ( 3
)
where i is the class index; prec i , rec i and F 1i are the precision, the recall and the F1-score of class i; N c is the number of classes; t p, f p and f n are the true positives, false positives and false negatives rates. All scores are averaged on 10 runs, with different initializations, and given with associated standard deviations, on our multi-domain testing subset.

Compactness of the Representation

We first evaluate the quality of the representations in a multi-domain setting. Table 1 reports the F1-score of CAKE-2, AV, CAKE-3 and AV1 trained on three datasets with three different classifiers, each one being specialized on a dataset as explained in Section 2. Among the 2-d models (AV and CAKE-2), AV is better, taking benefits from the knowledge transferred from the AffectNet dataset. This is not true anymore for the 3D models, where CAKE-3 is better than AV1, probably because of its greater number of trainable parameters.

To validate the hypothesis of the important gain brought by adding a third dimension, we run the "CAKE" and "AVk" experiments with different representation sizes. To simplify Rep. Dim. RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF] Covariance Pooling [ the analysis of the results, we plot in Figure 4 a multi-domain F1-score, i.e. the weighted average of the F1-scores according to the respective validation set sizes. We observe that the gain in multi-domain F1-score is exponentially decreasing for both representations -note that the representation size axis is in log scale -and thus the performance gap between a representation of size 2 and size 3 is the more important. We also observe that "CAKE" representations still seem to yield better results than "AVk" when the representation size is greater than 2. These first experiment shows that a very compact representation can yield good performances for emotion recognition. It also is in line with the "dominance" dimension hypothesis, as a third dimension brought the more significant gain in performance. After 3 dimensions, the gain is much less significant.

Accuracy of the Representation

To evaluate the efficiency of the CAKE-3 compact representation, we compare its accuracy with state-of-the-art approaches (Table 2) on the public datasets commonly used in the literature for evaluation (validation of SFEW and AffecNet, test of RAF). In order to get a fair comparison, we add a "Rep. Dim." column corresponding to the size of the last hidden representation -concretely, we take the penultimate fully connected output size. We report the scores under the literature's metrics, namely the mean of the per class recall for RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] and the accuracy for SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] and AffectNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF]. To the best of the author's knowledge no other model has been evaluated before on the AffectNet's seven classes. CAKE-3 is outperformed by Covariance Pooling [START_REF] Acharya | Covariance pooling for facial expression recognition[END_REF] and Deep Locality Preserving [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF]. Nevertheless, it is still competitive as the emotion representation is far more compact -3-d versus 2000-d -and learned in a multi-domain fashion. Moreover, we gain 1 point on RAF when we compare to models of same size (2 millions parameters), e.g. Compact Model [START_REF] Kuo | A compact deep learning model for robust facial expression recognition[END_REF]. These results support the conclusion made in 3.2, as we show that a compact representation of the emotion learned by small models is competitive with larger representations. This finally underlines that facial expressions may be encoded efficiently into a 3-d vector and that using a large embedding on small datasets may lead to exploit biases of the dataset more than to learn emotion recognition.

Our experiments also allow to perform a cross-database study as done in [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF]. This study consists in evaluating a model trained on dataset B on a dataset A. Thereby Table 3: Cross-database evaluation on CAKE-3 model (F1-Score).

Table 3 with the evaluation of each classifier on each dataset. Results on SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] -trained or evaluated -are constantly lower than others, with a higher standard deviation. This could be due to the insufficient number of samples in the SFEW training set or more probably to the possible ambiguity in the annotation of SFEW compared to AffectNet and RAF. Confirming this last hypothesis, the RAF classifier has the better generalization among the datasets. It is in line with the claim of Li et al. [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] that RAF has a really reliable annotation with a large consensus between different annotators. Finally, it also underlines the difficulty to find a reliable evaluation of an emotion recognition system because of the important differences between datasets annotations.

Visualizing Emotion Maps

Visualizations are essential to better appreciate how DNN performs classifications, as well as to visualize emotion boundaries and their variations across datasets. Our visualization method consists in densely sampling the compact representation space -2-d or 3-d -into a mesh grid, and feeding it to a formerly trained model -AV, CAKE-2 or CAKE-3 -in order to compute a dense map of the predicted emotions. Not all the coordinates of the mesh grid belong to real emotions and some of them would never happen in real applications. The construction of the mesh grid depends on the model to be used. For the AV and the CAKE-2 models, we have simply built it using 2d vectors with all values ranging in intervals containing maximum and minimum values of the coordinates observed with real images. As the CAKE-3 model is dealing with a three-dimensional representation, it is not possible to visualize it directly on a plane figure. To overcome this issue we modify CAKE-3 into a CAKE-3-Norm representation where all the coordinates are constrained to be on the surface of the unit sphere, and visualize spherical coordinates. Even if CAKE-3-Norm shows lower performances (about 2 points less than CAKE-3), the visualization is still interesting, bringing some incentives about what has really been learned.

Figure 5 shows the visualization results for CAKE-3-Norm, AV and CAKE-2 representations (resp. from top to down). Each dot is located by the coordinates of its compact representation -(arousal, valence) for AV, (k 1 , k 2 ) for CAKE-2 and spherical coordinates (φ and θ ) for CAKE-3-Norm -and colored according to the classifier prediction. The per class macro F1-score is displayed inside each emotion area.

First, each compact representation -CAKE-2, CAKE-3-Norm and AV -exhibits a strong consistency across the datasets (in Figure 5, compare visualizations on the same row). Indeed, the three classifiers show a very similar organization of the emotion classes, which is demonstrating the reliability of the learned representation. Thereby, the neutral class -in blue -is always placed at the origin and tends to neighbor all other classes. It is in line with the idea of neutral as an emotion with a very low intensity. Nevertheless, we can witness small inter-dataset variations, especially on SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] (in Figure 5, middle column) with disgust and fearresp. brown and purple -which are almost missing. This underlines the disparities of annotations across the datasets and confirms the need of multi-domain frameworks when wishing to achieve a more general emotion recognition model.

Second, we can analyze variations between the different representations for a given dataset (in Figure 5, compare visualizations on the same column). As AV is based on arousalvalence, we observe the same emotion organization as in Figure 1. Especially, as the majority of the AffectNet's training (and validation) samples have a positive arousal, the classifier do not use the whole space (in Figure 5, second row: see green, blue and orange areas) unlike CAKE-2 and CAKE-3 which are not constrained by arousal-valence.

We can find many similarities between these three representations, but the most impressive come across when comparing CAKE-2 and AV. Despite the inequality of scaling -which causes the neutral area (blue) to be smaller in CAKE-2 -AV and CAKE-2 compact representations are very close. Indeed, the area classes are organized exactly in the same fashion. The only difference is that for AV they are disposed in a clockwise order around neutral whereas for CAKE-2 they are disposed in an anticlockwise order. This observation shows that a DNN trained on the emotion recognition classification is able to learn an arousal-valence-like representation of the emotion. It contributes -along with Khorrami [START_REF] Khorrami | Do deep neural networks learn facial action units when doing expression recognition[END_REF] who points that DNNs trained to recognize emotions are learning action units [START_REF] Ekman | Measuring facial movement[END_REF] -to bring the dependence across the emotion representations in the forefront. , SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] and RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF].

Conclusion

This work proposes a comprehensive analyze on how a DNN can describe emotional states.

To this purpose, we first studied how many dimensions are sufficient to accurately represent an emotion resulting from a facial expression. We then conclude that three dimensions are a good trade-off between accuracy and compactness, agreeing with the arousal-valencedominance [START_REF] James | A circumplex model of affect[END_REF][16] psychologist model. Thereby, we came up with a DNN providing a 3-dimensional compact representation of emotion, learned in a multi-domain fashion on RAF [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF], SFEW [START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] and AffecNet [START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF]. We set up a comparison with the state-of-thearts and showed that our model can compete with models having much larger feature sizes. It proves that bigger representations are not necessary for emotion recognition. In addition, we implemented a visualization process enabling to qualitatively evaluate the consistency of the compact features extracted from emotion faces by our model. We thus showed that DNN trained on emotion recognition are naturally learning an arousal-valence-like [START_REF] James | A circumplex model of affect[END_REF] encoding of the emotion. As a future work we plan to also apply state-of-the-art techniques -as Deep Locality Preserving Loss [START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF] or Covariance Pooling [START_REF] Acharya | Covariance pooling for facial expression recognition[END_REF] -to enhance our compact representation. In addition, nothing warranty that the learned CAKE bears the same semantic meanings as arousal-valence-dominance does: further interpreting the perceived semantic of the dimensions would therefore be an interesting piece of work.

Figure 1 :

 1 Figure1: Comparison of the discrete and continuous (arousal-valence) representations using AffectNet's annotations[START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF].

Figure 3 :

 3 Figure3: Our approach's overview. Left: we use a ResNet-18 previously trained for discrete emotion recognition or arousal valence regression to extract 512-d hidden representations from face images. Center: using these hidden representations, CAKE or AVk representations (center) are learned to predict discrete emotions. Right: the learning process is multi-domain, predicting emotions on three different datasets with three different classifiers. Gray blocks are non-trainable weights while blue blocks are optimized weights.

  Compact embedding is obtained by projecting the 512-d features provided by the ResNet-18 (pretrained on discrete emotion recognition) into smaller k-dimensional spaces (Figure 3, Emotion Encoding) in which the final classification is done. The k features may be seen as a compact representation of the emotion, and the performance of the classifier can be measured for different values of k. CAKE-2, CAKE-3, etc., denote such classifiers with k = 2, k = 3, etc.

Figure 4 :

 4 Figure 4: Influence of representation size on the multi-domain F1 score.

-Figure 5 :

 5 Figure 5: Visualization of CAKE-3-Norm, AV and CAKE-2. Rows indicate evaluated representation -resp. from top to down: CAKE-3-Norm, AV, CAKE-2 -and columns indicateresp. from left to right: AffectNet[START_REF] Mollahosseini | Affectnet: A database for facial expression, valence, and arousal computing in the wild[END_REF], SFEW[START_REF] Dhall | Static facial expression analysis in tough conditions: Data, evaluation protocol and benchmark[END_REF] and RAF[START_REF] Li | Reliable crowdsourcing and deep localitypreserving learning for expression recognition in the wild[END_REF].

Table 1 :

 1 Evaluation of compact representations on AffectNet, SFEW, RAF.

Table 2 :

 2 Accuracy of our model regarding state-of-the-art methods. The size of the representation is taken into account. Metrics are the average of per class recall for RAF and accuracy for SFEW and AffectNet.

	1]	2000 512	79.4 -	-58.1	--
	Deep Locality Preserving [15]	2000	74.2	51.0	-
	Compact Model [14]	64	67.6	-	-
	VGG[15]	2000	58.2	-	-
	Transfer Learning [18]	4096	-	48.5	-
	ours (CAKE-3)	3	68.9	44.7	58.2
	ours (Baseline)	512	71.7	48.7	61.7

By "fully connected layer" we denote a linear layer with biases and without activation function.


D Corbally

B D'ayala

Adey

Z A Sabeur

P Melas

K Meacham

R Corbally

D D'ayala

B Adey

An Integrated Decision-Support Information System on the Impact of Extreme Natural Hazards on Critical Infrastructure

Keywords: Environmental Decision Support Systems, Data Analytics, Crisis Management, Critical Infrastructure, Natural Hazards, Risk Management, Climate Change, Black Swans, Stress Testing

d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The INFRARISK Decision Support Tool (IDST) version 2.0 [START_REF] Melas | IDST System v2.0. INFRARISK project deliverable D7[END_REF] is an information system tool that allows urban planners, civil engineers, crisis managers, urban development agencies and enterprise consortia to assess potential multiple risks from natural hazards to which critical infrastructure may be exposed. These may include earthquakes, landslides, floods or a combination of all. The IDST hosts specialized databases with supporting scenario simulations derived from models of a number of natural hazards allowing their likelihood of occurrence and intensity levels for different statistical return periods to be estimated at the locations of critical infrastructure elements. Two exemplar case studies have been considered using the IDST. These consist of two large European transport networks (road and rail), located in Italy and Croatia respectively. They demonstrate the use of the adopted generic and overarching INFRARISK methodology for the evaluation of risks which are engendered by natural hazards on critical infrastructure. The IDST has options for applying the risk methodology to other transport networks of interest, provided that the necessary input data is uploaded into the system. The development of the IDST required the deployment of phase driven software development tasks using an agile approach. The first version [START_REF] Meacham | IDST System Specification v1.0. INFRARISK project deliverable D7.1[END_REF] of the IDST specification was initially developed through consultation with a large number of domain knowledge experts and end-users, both within the project partnership and externally. The IDST specification v1.0 was focused on capturing the functionality requirements for the IDST decision-support system. This exercise has led to the development of the IDST System [START_REF] Melas | IDST system v1.0. INFRARISK project deliverable D7[END_REF] with its basic functionalities. Version 2.0 of the IDST was then extended to include more advanced functionalities of the IDST [START_REF] Melas | IDST System Specification v2.0[END_REF]. Specifically, it includes the following modules: The following sections, highlight the agile IDST architecture design and implementation of IDST v2.0 [START_REF] Melas | IDST System v2.0. INFRARISK project deliverable D7[END_REF].

Agile IDST System Design and Development

The IDST has been specified to integrate tools, databases and user interfaces in consultation with end users and knowledge experts in crisis management under INFRARISK. It is primarily a web-based system (or portal) which is user-accessible via a web browser on multiple client platforms (laptop, tablet, etc.) and operating systems (Windows, Linux, etc.). For the IDST v2.0, commonly used browsers are supported (e.g. Internet Explorer, Firefox), and run on Windows or Linux operation systems. The design of the graphical user interface (GUI) took into account multiple platforms, by exploiting the latest platform independent user interface (UI) toolkits. The IDST software system is deployed on a central server, which has secure remote access available for registered users and selected stakeholders. Access is enabled via HTTPS and, for the main IDST pages, the user will be required to be logged in using their existing user account information. The initial welcome page of the IDST is available to all users, therefore providing some background information about INFRARISK and the IDST while providing links to the secure parts of the portal. The IDST system is modular, i.e. based on multiple autonomous and interacting components. These include: The IDST uses the Django framework which allows multiple components to be incorporated easily, while we integrated the GUI features of these modules concurrently. Certain components were included as modules (or executables) and launched by the main IDST component (i.e. IDST Process Workflow Engine). The components were executed with their required inputs and the results returned either by direct visual display or indeed as input to a subsequent module within the workflow. Certain components were deployed as a web service, either on the same host as the IDST or another remote server. Modules which require significant processing time (e.g. greater than one minute) were made available as results in a pre-populated database since it would not be appropriate for the user to practically experience running these simulations dynamically. Some components have been included as look-up tables and provide fast access to pre-run simulation results. In any case, the GUI made use of Ajax calls to the IDST server for any browser requests (e.g. page updates) that require more than a few seconds to perform. The agile development of the IDST system scaled successfully by supporting a large number of concurrent users. Its databases are also scalable since they can handle a mix of structured and unstructured data. Additionally, the data is made available to authorized users, so that they can extract information for their own specific applications.

2.1

High Level Architecture Design Architecture The authentication of access of users in the IDST is based on the following services: 1-Local user account authentication (exclusive for administrators); and 2-Third party authentication services (for other users), e.g. Google, Yahoo, LinkedIn. Once the authentication mechanism is selected, the user is redirected to the respective site for login in. After a successful login, users access the IDST portal profile. The full profile information is required for completing user authentication. If permission is given by the administrator, then the IDST portal associates the user's profile with the provided account details and enabled access to the portal.

IDST Dashboard

After a successful login, the user is presented with the IDST Dashboard page (Figure 2). The dashboard enables the users to create and manage their own stress tests data, as well as access to exemplar case studies.

3.3

The IDST Process Workflow Engine

The IDST Process Workflow Engine (PWE) is designed around the Overarching Risk Management Framework (ORMF) concept [START_REF] Adey | Preliminary model, methodology and information exchange[END_REF], [START_REF] Hackl | Final Model Methodology and Information Exchange[END_REF]. The ORMF describes the various steps involved in carrying out a stress tests for an infrastructure network [START_REF] Van Gelder | Stress Test Framework for Systems[END_REF]. The ORMF consists of the following enacting steps as shown in Figure 3 below:

IDST Data Storage

The IDST stores various datasets in its database system. The database system is preloaded with datasets to support the basic case studies, e.g. geometry and characteristics of the Northern Italian road network. In addition, users can upload the necessary datasets in order to run their own stress tests. Generated results for stress tests can be also exported and used outside the IDST workflow for further analysis. The type of datasets the IDST system supports are:

• Infrastructure element characteristics such as road, rail lines, bridges, tunnels, embankments, intersections, etc. • Hazard models/maps (e.g. seismic, landslide, flooding) • Simulation results from stress tests

• Analysis results

IDST Models

The risk evaluation in the IDST is based on specialized models which are pluggable modules that compute transport network elements of various stages of the IDST workflow. These are classified into (a) hazard and (b) vulnerability models. Hazard Models provide information derived from numerical models of different hazards. This information specifies the relevant intensity levels, depending on the model inputs specified by the user for a particular scenario. Network Models estimate the probability of the various infrastructure elements experiencing different levels of damage, given the occurrence of a particular hazard scenario. During this step, fragility curves (Figure 4) are assigned to the network elements. Fragility curves, specific to a particular infrastructure element (e.g. bridge, tunnel, road segment, etc.), describe the vulnerability of that element to a particular hazard [START_REF] D'ayala | Fragility Functions Matrix[END_REF]. In order to estimate the probability of having a defined Damage State (DS) in any given network element, these fragility curves are used, in combination with the information from the hazard models, to estimate the likelihood of experiencing different levels of damage. Table 1 provides an overview of the typical damages states considered.

Network Element Characteristics

The user must define the individual characteristics for each type of element being considered within the stress test. These characteristics must be defined for each hazard that is deemed to affect the different types of elements on the network (hazards will affect different types of elements in different ways). For example, the user might choose to consider the effect of ground acceleration (from an earthquake) on bridges, or the effect of landslides on road segments. In each case, the appropriate hazard models and vulnerability models must be available within the IDST. Once the characteristics have been defined the user proceeds by clicking the "Upload Network Elements" button.

3.6.1

The IDST Hazard Scenario

The IDST hazard scenario is used to define a set of cascading hazard events to be considered for a particular stress test. In particular, a hazard event is the combination of (a) a hazard source, e.g. an earthquake; (b) a hazard event, e.g. a ground shaking caused by the earthquake; and (c) a model that describes that hazard event. In most cases the hazard model will require a detailed configuration and a dataset to operate upon, depending on the complexity of the model used. The hazard source in the first hazard event is considered as the primary hazard source which can trigger secondary hazard events, e.g. a landslide caused by the occurrence of an earthquake.

3.6.2

The IDST Network Scenario

The IDST network scenario allows the user to define multiple sets of network events. A network event is defined by a combination of a network type, e.g. a road network, a hazard event deemed to impact that element type, and a network model that assigns fragility functions to that element type. For each network event a dataset of network elements (bridges, road segments, tunnels, etc.) has to be considered. That set of network elements can be selected from the pre-populated IDST datasets for the case study regions which are confined by stress the test boundary polygon, or uploaded directly from the user, e.g. as a shape file. Risk estimation, i.e. damage state calculation, for each network event is carried out by using the appropriate hazard model along with the vulnerability models for each of the network elements to estimate the potential damage to each of the associated infrastructure elements. Risk evaluation can then be carried out considering the calculated damage state for each infrastructure element.

Case Study Using the IDST

In this section, a case study is presented which comprises a road network around Bologna in Northern Italy, see Figure 5 below. Full details of this case study can be found in [START_REF] Clarke | Case Study Results[END_REF]. The region covers approximately 990km2 and is located around the city of Bologna.

Figure 5 Northern Italy case study borders

For this road network, the hazard source was an earthquake, with ground acceleration considered as the primary hazard event. In addition, earthquake-triggered landslides were considered as a secondary, cascading, hazard for this stress test hazard scenario. Figure 6 shows the hazard scenario as defined through the IDST. The primary hazard event is a ground motion event which has assigned the INFRARISK GM hazard model [START_REF] Jimenez | INFRARISK Technical Report Development of Seismic Hazard Modelling for Low-Probability Extreme Ground Motions[END_REF] assigned to it to allow the ground acceleration within the case study region to be calculated at the location of the various road infrastructure elements. An earthquake-triggered landslide hazard event is defined as a secondary event which utilizes a pre-loaded model for calculating locations where landslides may occur due to ground shaking.

Figure 6 Northern Italy case study hazard scenario

The impact of ground motion on bridges and tunnels is considered along with the effects of earthquake-triggered landslides on road sections. Figure 7 shows the network scenario for this stress test. The targeted infrastructure is the road network. Selected network element types are bridges and tunnels, where the associated hazard event is the ground motion and the assigned vulnerability models are bridge and tunnel fragility functions. The whole area around Bologna shown in Figure 7 is defined as the spatial boundary.

Figure 7 Northern Italy case study network scenario

The network element datasets used for this case study are selected from the IDST case study database which has been pre-populated with relevant characteristics for the elements in the region of the Italian case study. As shown in Figure 8, the system has identified 328 bridges and 30 tunnels included within the spatial borders of the region considered for this stress test. Figure 9 shows the locations of each of these elements, a heat map of ground acceleration values which correspond to the ground motion for an earthquake scenario considered for the stress test. At this point the system proceeds with risk estimation for this stress test. The appropriate fragility functions are assigned to each identified network element, i.e. tunnels and bridges and the likelihood of each element experiencing different levels of damage is calculated. This information can then be used to calculate direct and indirect consequences associated with the earthquake. Figure 10 shows the levels of Damage States and the statistical aspects of some of the respective direct consequences by the IDST.

Conclusion and Future Work

The IDST as a decision-support tool has concretely enabled civil engineers and critical infrastructure management stakeholders set up cascading risk scenarios with low probabilities of occurrence and high impact on and damages to Critical Infrastructure (CI).

The IDST was successfully demonstrated to the referred communities of specialised CI engineering firms and stakeholders at a large scale INFRARISK project conference [START_REF] Sabeur | The Integrated Decision Support Tool[END_REF]. The integration of the heterogeneous data sources, information and outputs under specialised databases and modelling tools in the IDST gives a unique common operational picture for the engineering communities who specialise in the management of CIs. Furthermore, the overarching risk assessment methodology which provides an automated Process Workflow Engine in the IDST clearly enables crisis management experts to usefully set "what if" scenarios on exposure of urban CIs to extreme natural hazards. The next step of this research and development work is for testing the scalability the IDST system towards architectures for supporting very large spatial coverages, mining of big data sources and extreme analytics for the computation of highly complex cascading risks of extreme and rare natural events on CIs. This is clearly a big data problem and challenge which can be met with supporting cloud and high perfor-mance computing infrastructure in the future. This will be our research goal for advancing our understanding and quantification of the socio-economic impact of very complex cascading natural hazards on CIs in Europe and beyond.

3 -

 3 User authentication and authorization, management functionalities; 4-GIS Map Engine; and 5-Visualization and Reporting tools.

Figure 1

 1 Figure1below, presents a high level conceptual view of the IDST modular architecture. This shows the main components in the system and how they fit together and interact. The IDST system consist of three layers. These are: 1) Presentation Layer; 2) Data Processing Layer; and 3) Data Storage Layer. The Presentation Layer is responsible for the creation of all of the content (as HTML) for the user's browser. It consists of a main component called the 'Portal', which handles user requests and delegates to

Figure 1 :

 1 Figure 1: High level conceptual architecture of the IDST

Figure 2

 2 Figure 2 IDST Dashboard

Figure 3

 3 Figure 3 IDST Workflow

Figure 4

 4 Figure 4 Illustrative bridge element fragility curves

Figure 8 Figure 9

 89 Figure 8 Stress test infrastructure datasets

Figure 2

 2 Figure 2 Stress tests Damage State analysis and statistics

Table 1

 1 Damage State (DS)

Acknowledgements

INTRARISK is funded by the European Commission's FP7 programme, Grant Agreement No. 603960. Further information can be found at www.infrarisk-fp7.eu. The authors gratefully acknowledge the contributions of the other INFRARISK consortium partners: Draga-dos SA, Gavin and Doherty Geosolutions Ltd., Probabilistic Solutions Consult and Training BV, the Spanish National Research Council, PSJ, Stiftelsen SINTEF and Ritchey Consulting AB.


Zachary T Reinhart

Sunil Suram
email: sunils@iastate.edu

Kenneth M Bryden
email: kmbryden@iastate.edu

A Domain Specific Language to Simplify the Creation of Large Scale Federated Model Sets

Keywords: federated modeling, integrated modeling, complex systems

This paper presents an attempt to address the challenge of modeling complex systems in which people, energy, and the environment meet. This challenge is met by developing a simple domain specific language for buiding systems models in a federated modeling environment. The language and its support infrastructure are designed for simplicity and ease of use. This language is demonstrated using a thermodynamic model of a biomass cookstove for the developing world as an example, and the use of the tools described in this paper to further extend that cookstove model into an end-to-end design tool for cookstoves and other energy systems for the developing world is discussed.

Introduction

Sustainability is the challenge of the future. Understanding systems in which people, energy, and the environment intersect will be critical in meeting this challenge. Modeling these large-scale complex systems will be key in gaining this understanding. However, creating these complex, integrated models is challenging. Traditionally, models for each of these domains have been built independently by researchers working in different, often unconnected fields. Integrating these disparate models to create a holistic systems model and that accurately represents these systems in which people, energy, and the environment intersect is difficult, time consuming, and expensive with conventional approaches. One approach to this model integration challenge is the development of federated model sets [START_REF] Bryden | A Proposed Approach to the Development of Federated Model Sets[END_REF].

Background

Integrated modeling has largely been developed by the environmental modeling community as an answer to the challenge of modeling large, complex systems. The goal of integrated modeling is to take a variety of components, be they mathematical models, databases, or other data sources, and combine them together into an integrated systems model [2]. A model integration framework is often utilized to achieve this integration. Various open-and closed-source model integration frameworks have been created, each with slightly different goals. For example, SCIRun [3] and OpenDX [START_REF]OpenDX[END_REF] have a visualization focus, while others focus on providing a component-based approach to model integration, such as the Object Modeling System (OMS) [START_REF] David | A software engineering perspective on environmental modeling framework design: The Object Modeling System[END_REF], The Invisible Modeling Environment (TIME) [START_REF] Rahman | It's TIME for a new environmental modelling framework[END_REF], and the Community Surface Dynamics Modeling System (CSDMS) [START_REF] Peckham | A component-based approach to integrated modeling in the geosciences: The design of CSDMS[END_REF]. Others, such as VE-Suite [START_REF] Mccorkle | Using the Semantic Web technologies in virtual engineering tools to create extensible interfaces[END_REF], seek to be general purpose model integration tools. Closed source packages such as Matlab™, Simulink™, [9] and Aspen Plus™ [10] can be considered as model integration tools, though they tend to be less flexible and are often focused on a specific domain, such as process plant simulation in the case of Aspen Plus.

The drawback of most integrated modeling frameworks is that they require significant effort in project management and software development to create the desired integrated model, and in some cases they lack the ability to utilize and manage large-scale, high-fidelity models needed for detailed analysis. Typically, full access to the source code of all constituent models is required, and the system builder or team must develop a global ontology that connects all models. This approach tends to produce a well-integrated product, but the challenges of management, software development, and global ontology development can become unwieldy when modeling large systems with myriad component models.

There have been attempts to address this shortcoming. The CSDMS implements a component-based programming model that is intended to minimize invasive changes to component models. This is achieved through a pair of software interfaces, the Basic Model Interface (BMI) and the Component Model Interface (CMI) [START_REF] Peckham | A component-based approach to integrated modeling in the geosciences: The design of CSDMS[END_REF][START_REF]Community Surface Dynamics Modeling System Basic Model Interface (BMI)[END_REF][START_REF]Community Surface Dynamics Modeling System Component Model Interface (CMI)[END_REF]. The BMI is the interface to the component model, and the CMI is the corresponding interface that connects to the integration framework. Once the code of a component model has been modified to implement the BMI, it can be registered as a usable component model within the CSDMS framework [START_REF] Peckham | A component-based approach to integrated modeling in the geosciences: The design of CSDMS[END_REF][START_REF]Community Surface Dynamics Modeling System Component Model Interface (CMI)[END_REF]. While this approach was originally created for large-scale geological modeling, Antonelli, Bryden, and LeSar [START_REF] Antonelli | A model-to-model interface for concurrent multiscale simulations[END_REF] have adapted the BMI to link a molecular dynamics simulation with a lattice Boltzmann solver to form a concurrent multi-scale model of fluid flow, demonstrating the applicability of the BMI concept to other types of models and systems.

Another approach is the development of federated model sets [START_REF] Bryden | A Proposed Approach to the Development of Federated Model Sets[END_REF]. Federated model sets have been envisioned to take advantage of cloud-based independent models and to enable rapid construction of complex system models from these cloud-based independent modeling components. Specifically, in a federated model set, component models are implemented as independent information services with self-documenting interfaces. Information transfer between models is brokered, allowing for the creation of peer-topeer ontologies instead of a global ontology for the integrated model. Component models can maintain a high level of autonomy and independence while still being members of a larger system model. This independence streamlines component and system model development and project management through a clear separation of roles.

In a federated modeling system, there are three primary user roles: the component modeler, the system builder, and the end user. The component modeler provides the constituent component models that can be utilized to build systems models. The system builder selects component models and composes a systems model. The end user utilizes the systems model to answer questions or gain insight into the modeled system. While these roles may overlap, they can be totally independent. The component modeler need not coordinate development with the system builder; they need only to provide their model in the required format with proper library entries and message contracts for inclusion in the federated modeling system. System builders may choose freely from these component models to construct systems models.

Suram, MacCarty, and Bryden [START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF] have implemented a proof-of-concept federated model set based on a heat-transfer model of a small, shielded-fire cookstove for the developing world developed by MacCarty and Bryden [15]. This model was decomposed into seven independent information services, each implemented as a stateless web microservice [START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF][START_REF] Thönes | [END_REF]. These microservices fulfill requests for computation; each request must contain all information necessary to fulfill the request, and after the results of the computation are returned, all state is discarded. As currently implemented by Suram, MacCarty, and Bryden [START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF], a federated modeling system has the following characteristics.

• Models as stateless microservices • Message broker for communication between microservices and infrastructure services • A programmable federation management system (FMS) • Simple message contracts • Web-based front-end server These characteristics can be leveraged to create a system model that is accessible as a dynamic web service, but to do so the system builder must write code in Java that coordinates with the FMS to route data through the selected system of models. Any translation that is necessary between adjacent models must be handled manually by the system builder. Creating, modifying, and utilizing a federated modeling system as it exists now requires the system builder to be an expert in cloud computing and app development. However, by creating a domain specific language (DSL) and supporting infrastructure, we can substantially simplify the process of creating a federated model set, making it approachable for many more users.

A DSL is a custom programming language designed for a specific problem domain, built using the idioms and concepts of that domain [START_REF] Van Deursen | Domain-specific languages: an annotated bibliography[END_REF]. The advantages of DSLs over general purpose languages include increased productivity and more readable, maintainable, and reusable code, among others. One of the chief advantages of a DSL for complex system modeling is that it enables clear communication with domain experts [START_REF] Van Deursen | Domain-specific languages: an annotated bibliography[END_REF][START_REF] Fowler | Domain-specific languages / Martin Fowler[END_REF]. Since a DSL natively uses the concepts and idioms of the domain in question, code in that language is easily read, understood, and written by domain experts even with limited programming experience [START_REF] Van Deursen | Domain-specific languages: an annotated bibliography[END_REF][START_REF] Fowler | Domain-specific languages / Martin Fowler[END_REF]. DSLs strive for fluent translation between mental models and code. This is a significant advantage when building models of complex systems, and is our primary motivation in designing a DSL for federated modeling.

Language Discussion

To create a working federated model set, four pieces of information are necessary:

• A list of constituent models,

• A list of connections between models,

• A list of input parameters,

• A list of desired output variables.

The desired component models and system level inputs and outputs are usually straightforward to define. The connections between models are generally much more complex to define fully. However, many of these connections can be determined automatically by the DSL tools by leveraging the self-describing interfaces of the constituent models along with supporting infrastructure. Therefore, the focus of the DSL is to allow the system builder to specify the constituent models, inputs, and outputs in a straightforward manner, with less emphasis on fully defining detailed connections between models. By removing this burden of complexity, the syntax of the language can be made readable and intuitive, even to those users who have limited programming experience.

To that end, we have laid out a simple syntax that consists of three types of text blocks: input blocks, output blocks, and system blocks, illustrated in Fig. 1. These blocks may appear in any order in a system script. The input and output blocks do not need to be placed ahead of the system block, for example. The syntax avoids the use of brackets, braces, and other symbols whose purpose may not be obvious to new users. There are two types of input blocks, user inputs and constants. User inputs are passed in by the end users of a model. Since a federated model set is implemented as a web service, inputs will be uploaded to a specific web location. Constants are specified by the system builder, either in the code they write or in a file. The file location may be specified as a valid uniform resource locator (URL). Output blocks simply specify the output variables of interest. These outputs will be available for download at a specified URL upon completion of the requested modeling job. The system block contains a list of the models that constitute the system, along with the address of the model library from which these models are drawn. In many cases, these models can just be listed by their unique names as looked up in the component library. They do not need to be listed in any defined order. In cases where it is necessary for the user to define some of the connections between models, the following syntax is used:

model_a, model_b -> model_d
where model_a and model_b represent the names of two models that are providing inputs to a third model, named model_d. This syntax could be extended to allow the system builder to specify specific variables from source and destination models if needed.

To maintain this level of simplicity, supporting software infrastructure within the federated modeling environment is required. The critical enabling infrastructure services are the model library services and the message contract database. The DSL interpreter will rely on these services to determine possible workflows for solving the specified models [START_REF] Mcnunn | A Proposed Implementation of Tarjan's Algorithm for Scheduling the Solution Sequence of Systems of Federated Models[END_REF]. These services and their use will be discussed in the next section.

Support Infrastructure Discussion

As mentioned above, the model library service and the message contract database are the key infrastructure services for enabling the simplicity of our DSL. The model library service is straightforward. It is a database that stores information about each component model available in a federated modeling system. Each record in the database corresponds to one component model, and will have information such as a unique name, a network address for the model microservice, a human-readable description, and other relevant data and metadata. Among this data is a full list of required and optional inputs and outputs in the form of message contract references. All data transfer between models in a federated model set is governed by a system of "snappers" [START_REF] Bryden | A Proposed Approach to the Development of Federated Model Sets[END_REF] or message contracts [START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF]. Taken together, these message contracts and their corresponding connections on component models form an extensible system of complex composite data types that enables peer-to-peer ontologies to be negotiated between adjacent communicating models [START_REF] Bryden | A Proposed Approach to the Development of Federated Model Sets[END_REF]. A message contract takes the form of a document or database record that contains the following fields:

• A globally unique identifier (GUID),

• A list of variables, including name, data type, and description for each,

• A human-readable name, • A brief description.
This information is used as the basis for a mediated negotiation between two models, with the FMS serving as the mediator. First, the FMS checks that the output of the source model and the input of the destination model are referencing the same message contract GUID. This ensures a basic shared vocabulary of variable names and data types. The interfaces of the models also incorporate questions and answers, or constraints, that are used to further negotiate data exchange. At minimum, these constraints should define the units for all variables. Simple, scalar unit conversions will be performed by the FMS. In addition, other optional constraints can be imposed by component modelers, such as valid input and output ranges, ranges of accuracy or stability, invalid inputs due to discontinuities, etc. If acceptable answers are found to all required question/answer pairs between two models, a peer-to-peer ontology is defined and the models may communicate freely.

This process is most easily understood by examining an example. Consider the following two component models drawn from MacCarty and Bryden's [START_REF] Maccarty | An integrated systems model for energy services in rural developing communities[END_REF] village energy model, which is being modularized for use in a federated modeling system. The model presented in [START_REF] Maccarty | An integrated systems model for energy services in rural developing communities[END_REF] is an integrated model of the comprehensive energy use of a small African village composed of smaller component models. We will select two models that are used internally, the fuel collection model and the fuel cost model. The fuel collection model takes several inputs and provides an output of the number of annual hours of a given fuel type. The fuel cost model takes the annual hours of a given fuel type as an input, among others, and produces the annual cost of fuel collection time for a given fuel as an output.

We define a message contract to facilitate this connection. The contract is assigned a GUID by which it will be referenced. It defines a data interchange containing two variables: a floating-point variable named hours containing the time quantity, and a string variable named type containing the fuel type. Each model would reference the GUID and have a set of constraints, which would be the unit for time, hours, a constraint that values be positive, and the requirement that the fuel be of a known type. The two models and their message contract are illustrated in Fig. 2.

Once the model library and the message contract system are in place, the DSL tools can utilize the data within both systems to infer connections within model sets and calculate computational workflows to solve model sets. The inputs and outputs of a given component model together with the referenced message contracts allow the system to create a list of possible connections that are valid. That is, for any given input or output of a model, a list of compatible other models can be created. In some cases, there will be a unique set of compatible connections between the component models listed in the Fig. 2. Illustration of model input/output and matching message contract. DSL script. In this case, the system builder will not have to explicitly specify any connections between models. When there are multiple valid sets of connections between specified component models, the DSL tools will provide detailed feedback on the points of ambiguity to the system builder. The system builder can then use the syntax defined in the previous section to select one among the possible valid connections where the ambiguity exists. In this way, the DSL tools and the system builder form a partnership, with the system builder offering clarifying information when necessary instead of having to be concerned with the details of every connection between the cloud-based component model microservices in a model set. In the next section, we will explore how all this will work with a real system by applying these tools to the cookstove model used by Suram, MacCarty, and Bryden in [START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF].

5

Example and Discussion

Cookstove Model Example

Most of the energy requirements for families in the developing world are currently met by three stone fires [START_REF]Energy Poverty: how to make modern energy access universal? Special Early Excerpt of the World Energy[END_REF][START_REF] Johnson | Energy supply and use in a rural West African village[END_REF]. However, three stone fires are inefficient, dangerous, and have significant negative environmental impact [START_REF] Lim | A comparative risk assessment of burden of disease and injury attributable to 67 risk factors and risk factor clusters in 21 regions, 1990--2010: a systematic analysis for the Global Burden of Disease Study[END_REF][START_REF] Bond | Can Reducing Black Carbon Emissions Counteract Global Warming?[END_REF]. Improve biomass cookstoves have been developed to address the shortcomings of the three stone fire. Such a cookstove typically consists of a combustion chamber, a grate to elevate the fuel for better airflow, and geometric features to direct the flow of hot gases from the fire around the pot, improving heat transfer [15]. Fig. 3 shows a representation of this type of cookstove. Improved biomass cookstoves are key components of energy interventions in the developing world, but there is a dearth of modeling and design tools for such This model breaks the cookstove into three coupled zones: the fuel bed zone, the flame zone, and the heat transfer zone, as shown in Fig. 3(A). Solid phase combustion is modeled in the fuel bed zone, gas phase combustion in the flame zone, and heat transfer to the pot and the environment is modeled in the heat transfer zone. Buoyancy driven fluid flow is modeled throughout the coupled zones [15]. This model has been implemented in [START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF] as seven component model microservices, which are summarized in Table 1.

Originally these models were federated manually with custom Java code. To leverage our proposed domain specific language, model library entries would be created for each model, along with an appropriate system of message contracts. For brevity's sake, the creation of the various message contracts will not be discussed in depth here. The strategy is to create a single message contract for each interacting pair of models. The connections in this system are simple, so only a handful of message contracts are necessary. As discussed earlier, the creation of the model library entries and message contracts is the responsibility of the component model builder, not the system builder. The system builder should find all those things in place and validated for any component model that is listed as ready to use.

With the library entries and message contracts in place, we can now represent this system in the domain specific language. Since message contracts were constructed specifically for the connections necessary in this system, there is only one valid set of possible connections, and the system builder will not need to explicitly specify any connections. Thus, the code representing the system model becomes: In the above code, the inputs block contains the specified input variables. These are geometric parameters for the stove. Briefly, they are the height of the pot shield, H_sh; the width between the pot shield and the pot, W_sh; the width of the gap between the pot and stove at the corner of the pot, W_pot; the distance from the bottom of the pot to the top of the combustion chamber, W_c; the height of the combustion chamber, H_c; the inner and outer diameters of the combustion chamber, D_c and D_stove; the diameter of the pot, D_pot; and the height of the pot, H_pot. These correspond to the geometric parameters show in Fig. 3 (B). The constants block contains a URL that points to a data file in JavaScript Object Notation (JSON) format. This file lists all necessary constants to run the model. The outputs block specifies the output of interest, thermal efficiency. The system block simply lists the seven component models shown in Table 1 that make up the cookstove model.

inputs
In a federated modeling environment, this would be the only code necessary to create the cookstove model as a web service. When run, the system would check the code, instantiate model microservices as necessary, create appropriate URLs for inputs and outputs, and provide those addresses along with status messages to the end user. The set of input and output URLs form an application programming interface (API) to the systems model, as used in web app development. An intuitive graphical user interface for modifying geometric stove parameters and visualizing the resulting performance of the stove could be built around this API.

Extensibility Discussion

The above model allows users to design cookstoves based on thermal efficiency. However, cookstoves for the developing world are intended to improve quality of life through better health outcomes and reduced environmental impact. The current cookstove model does not account for any of these factors, but it could form part of a systems design tool that does. By utilizing models from domain experts in energy systems for the developing world and sustainable agricultural and integrating these models with the cookstove model, a design tool that provides feedback in terms of health outcomes and environmental impact could be created.

MacCarty and Bryden [START_REF] Maccarty | An integrated systems model for energy services in rural developing communities[END_REF] have identified the following factors as significant in prediction the adoption and impact of any energy device in the developing world:

• Desirability -perceived quality and aesthetic benefit • Disruption -ability of stove to fit existing cooking patterns • Convenience -ease of use and amount of attention required • Safety -safety of the device for the user and family have developed an integrated systems model [START_REF] Maccarty | An integrated systems model for energy services in rural developing communities[END_REF] that accounts for these factors encompasses all the common energy needs in rural villages in the developing world. This model takes as input a set of energy components such as cookstoves, lighting equipment, water heating systems, etc., and performs a Monte Carlo simulation to predict the outcomes for a village, including energy access, environmental effects, health impact, cost, quality of life.

Of major concern when considering any energy intervention in the developing world is environmental impact. While this impact occurs in many forms, including CO2 and black carbon emissions, deforestation [START_REF] Maccarty | An integrated systems model for energy services in rural developing communities[END_REF] and its impact on local agriculture should also be considered. Muth and Bryden [START_REF] Muth | An integrated model for assessment of sustainable agricultural residue removal limits for bioenergy systems[END_REF] have developed an integrated systems model to predict sustainable levels of agricultural residue removal. This integrated model incorporates several existing models for soil erosion and agricultural databases to create a tool that can predict the sustainability of a given farming practice at a high resolution anywhere in the United States. This model is becoming the standard for modeling sustainable agricultural processes in the United States, and it could be easily adapted for other places in the world.

By modularizing both the village energy model and the sustainable agricultural residue model and implementing them in a federated modeling environment, it becomes simple to modify them and integrate them into a new design model. The thermal efficiency from the cookstove model would become an input to the village energy model, and biomass remove rates from village energy model would become inputs into the sustainable agriculture model. The sustainable agriculture model would be modified with the appropriate databases to predict soil erosion and conditions in the developing world.

This would yield an end-to-end design tool that could predict health, environmental, agricultural, and energy outcomes for the developing world based on material and geometric design changes to the cookstove being designed. It would also be straightforward to extend this design tool with physical models of other energy devices being considered for the developing world, giving designers, aid workers, and policy makers a powerful tool to predict the real-world impact of holistic, village-wide energy systems design in a way that has not been possible before. A conceptual representation of this is shown in Fig. 4.

Since each component and subcomponent would exist as an independent web microservice, each model could be maintained and updated by domain experts. The domain experts in each field could retain ownership of their models, even as those models become constituent parts of the integrated end-to-end stove design model. Further, the stove design model will automatically benefit from improvements in the performance, capability, and accuracy of the underlying constituent models.

Conclusion and Future Work

This paper presents a proposed domain specific language and supporting infrastructure for rapidly and fluently creating systems models in a federated modeling environment.

This not only simplifies model development and team management, but also enables more informed decision making based on rapidly developed end-to-end models of complex systems in which people, energy, and the environment meet. Further research is needed to demonstrate the capabilities envisioned here and integrate the set of environmental and other models needed to create the stove design tool as presented.

Fig. 1 .

 1 Fig. 1. Brief syntax for code blocks.

Fig. 3 .

 3 Fig. 3. (A) Biomass cookstove with modeling zones. Adapted from [25]. (B) Geometric stove design parameters. Adapted from [15].

Table 1 .

 1 Constituent models of cookstove federated model set, after[START_REF] Suram | A generalized heat-transfer model for shielded-fire household cookstoves[END_REF].

	stove_model
	H_sh
	W_sh
	W_pot
	W_c