Ingomar Wenzel

Bernhard Rieder
email: bernhard@vmars.tuwien.ac.at

Raimund Kirner
email: raimund@vmars.tuwien.ac.at

Peter Puschner

Automatic Timing Model Generation by CFG Partitioning and Model Checking *

In this paper we present a new measurement-based worst-case execution time (WCET) analysis method. Exhaustive end-to-end measurements are computationally intractable in most cases. Therefore, we propose to measure execution times of subparts of the application. We use heuristic methods and model checking to generate test data, forcing the execution of selected paths to perform runtime measurements. The measured times are used to calculate the WCET in a final computation step. As we operate on source code level our approach is platform independent except for the run time measurements performed on the target host.

We show the feasibility of the required steps and explain our approach by means of a case study.

Introduction

Due to the temporal constraints required for correct operation of a real-time system, predictability in the temporal domain is a stringent imperative to be satisfied. Therefore, it is necessary to determine the timing behaviour of the tasks running on a real-time computer system. Worst-case execution time (WCET) analysis is the research field investigating methods to assess the timing behaviour of real-time tasks.

A central part in WCET analysis is to model the timing behaviour of the target platform. However, hardware modelling is a time-consuming task for modern processor hardware [START_REF] Heckman | The influence of processor architecture on the design and the results of WCET tools[END_REF]. In order to avoid this effort and address the portability problem in an elegant manner, we developed a new hybrid WCET analysis approach performing execution time measurements on the instrumented application executable to obtain the required hardware timing model [START_REF] Kirner | Measurement-Based Worst-Case Execution Time Analysis using Automatic Test-Data Generation[END_REF]. From the approach presented in [START_REF] Kirner | Measurement-Based Worst-Case Execution Time Analysis using Automatic Test-Data Generation[END_REF], two challenges arise: (i) the granularity of the items subject to measurements has to be determined and (ii) the measurement subsystem has to force the corresponding measurements on the target hardware.

The first contribution of this paper is the development of an automatic control flow graph (CFG) partitioning method to identify the units subject to these measurements (Section 2). Second, we introduce model checking for generating test data that allows the systematic measurement of the selected paths. We show that there exists a reasonable tradeoff between the number of instrumentation points and the number of measurements necessary in order to cope with the complexity inherent in real-time program code (Section 3). The practical applicability of our method is illustrated by a case study from the automotive domain. It consists of an application automatically generated by the TargetLink code generator from dSpace [START_REF]dSpace TargetLink[END_REF] (Section 4).

Control Flow Graph Partitioning

In this section, we present our method for automatically partitioning the control flow graph into these subparts that will later be used as smallest granularity items in our execution time model.

Basic Concepts

Before proceeding, we introduce some terms. A basic block denotes a sequence of consecutive statements in which flow of control enters at the beginning and leaves at the end, without the possibility of branching except at the end of the basic block [START_REF] Aho | Compilers -Principles, Techniques, and Tools[END_REF].

The control flow graph (CFG) is a directed graph that consists of linked basic blocks with one distinguished initial node (whose first instruction is the first instruction in the program). Due to the fact that it is impossible to use endto-end measurements covering all paths, we partition the code using the notion of program segments (PS). A PS is a subgraph of the CFG that can be entered only via the transition of a single control edge, multiple exit edges are possible. A structured program segment (SPS) is a PS that has only a single exit edge.

After partitioning the program into program segments, instrumentation points are introduced before and after the program segments. Execution time measurements of individual PS are used to calculate the WCET bound of the whole program.

Partitioning the Control Flow

The CFG is partitioned into PS following the abstract syntax tree. This partitioning is then used to determine the necessary instrumentation points and the number of measurements needed to evaluate the program. During the partitioning step the CFG is traversed hierarchically top-down. The decision whether a PS is analysed as a whole (i.e., all paths of the PS are measured by instrumenting the PS at its beginning and end) depends on the number of paths inside the PS. Whenever a PS is identified to be analysable as a whole, no further analysis of subordinated PS is performed.

The partitioning algorithm works as follows. As a starting point, the whole function subject to the analysis process is considered as one PS.

Whenever the number of paths within a PS is less or equal some given bound b, measurement points are inserted at the beginning and the end of the PS. Thus, the number of instrumentation points ip increases by 2 and the number of measurements m is increased by the number of paths within that PS.

If the number of paths within the PS is higher than path bound b then the PS is decomposed and the execution times of its constituents (nested PS; the smallest unit of PSs are basic blocks) are measured. Figure 1 presents an example code listing with its associated CFG. The nodes in the CFG of Figure 1 are labelled with the line numbers of the first instruction of the respective basic block.

Table 1 shows the estimated measurement effort for the analysis of the sample program. For bound b = 1 the number of instrumentation points equals 22 since every single basic block is measured. For b = 2, an if statement containing 2 paths is measured as a whole PS. Thus, the four basic blocks having the id values

Tradeoff between Instrumentation Points and the Number of Measurements

We examined the relationship between the path bound b, the number of instrumentation points ip and the number of measurements m when using an existing automotive application code which is generated by the TargetLink code generator [START_REF]dSpace TargetLink[END_REF] out of Matlab/Simulink models. The source files of this application, with all include files resolved, have an average size of approximately 5000 lines of code, the analyzed functions have around 800 basic blocks and about 300 conditional branches.

Figure 2 outlines the relationship between the path bound b and the number of instrumentation points ip (note that the scaling of the x-axis is logarithmic). For b = 1 the number of instrumentation points equals the doubled number of nodes in the CFG (i.e., 857 * 2 = 1714), which is due to the stand-alone instrumentation of each basic block. When incrementing the path bound b, the number of instrumentation points decreases. Considering the right tail of the line, even huge increments of the bound b result only in minor instrumentation point reductions.

It is important to bear in mind that this plot -as well as all the subsequent ones -depicts the situation for a specific piece of code.

Figure 2. Number of instrumentation points over path bound b

The relation between the number of instrumentation points ip and the number of measurements m is depicted in Figure 3. From higher to lower numbers of instrumentation points an explosion in the number of required measurements can be observed. End-toend measurements would be performed at the point where ip = 2, increasing m to an computationally intractable value. The arrows inside the diagram outline the changing costs between instrumentation and measurement.

Our first implementation of a simple code partitioning algorithm was able to keep the number of instrumentation points as low as 500 1 .

We are currently extending the CFG partitioning algorithm to produce a general PS partitioning. This is expected to result in improvements in the number of instrumentation points at low measurement cycle costs.

Figure 3. Measurement cycles and instrumentation points 3 Test Data Generation

From the static code analysis performed during the control flow partitioning the paths to be measured are known. To perform measurements of selected program segments we need test data that lead to the execution of the selected path segments.

A method of generating test data is model checking, see [START_REF] Hong | Data Flow Testing as Model Checking[END_REF]. If there exists a test data pattern that leads to the execution of a distinct path it will always be found with model checking. The drawback of model checking is its calculation cost. For this reason a hybrid approach has been chosen: first, test data are generated using heuristic methods (i.e. genetic algorithms) until a given coverage bound is reached. A possible bound could be that no new paths have been reached with the last 10 6 generated data patterns. The bound is necessary to stop calculation at a point where the costs to find new paths with heuristic methods equal the costs of finding new paths using model checking.

According to [START_REF] Tracey | Systems Engineering for Business Process Change: New Directions, chapter A search-based automated test-data generation framework for safety-critical systems[END_REF] we expect heuristic methods to generate more than 90% of the required test cases. In a second step the remaining test data are generated using model checking. If no data pattern is found for a selected path the path is deemed infeasible.

We use the SAL model checker from SRI Labs [START_REF] De Moura | SAL 2. To be presented at CAV 2004[END_REF] for test data generation. For this purpose, the C source code is converted into the SAL Language.

State Space

An important goal for the C-to-SAL conversion is to keep the state space of the model as small as possible. Assuming a model with n variables x i with domain D i , the domain of the state vector x = (x 1 , . . . , x n ) is

D = D 1 × D 2 × . . . × D n .
The reachable state space D R is a subset of D. D R depends on the set of initial values of the variables, which is denoted as D I . According to the communication from a developer of the model checker SAL, the number of bits required to encode the state vector x should not exceed 700 to get acceptable performance on currently available personal computers.

Direct conversion without any semantic knowledge is very inefficient: In C, boolean values are mostly encoded as 16 bit integers where a single bit would suffice. If boolean values are encoded in the SAL model in the same way, i.e. as integers, about 44 boolean values would fill up the complete state space, whereas 700 booleans could be processed if a single-bit encoding were used.

Optimisations to reduce the State Space

Basically there are two properties that affect the efficiency of a model: The size of the state space and the number of transitions that are required to reach the goal (i.e. to generate a counter example). We use optimisations to reduce either of these values. The optimisations presented in this paper not only increase the performance of the model checker but also allow model checking of programs that would be too big otherwise. The presented optimisations do not change the model. Instead, we use these optimisations to make the representation of the model more compact, thus reducing the state space and increasing the model checker performance.

Some of the techniques presented here are also applied in compiler technology and are comprehensively described in [START_REF] Aho | Compilers -Principles, Techniques, and Tools[END_REF]. The majority of optimisation techniques described in [START_REF] Aho | Compilers -Principles, Techniques, and Tools[END_REF] introduce new temporary variables. When they are used for model checking this would increase the state space and therefore degrade the performance.

Reverse CSE

This optimisation is the contrary to Common Subexpression Elimination (CSE) known from compilers.

Temporary variables containing intermediate results are replaced by the values that are assigned to them. For instance, the sequence a=b+1; c=a+b; d=a*2; is replaced by c=(b+1)+b; d=(b+1)*2; The performance loss from recalculating the subexpression is small compared to the gain from the reduced state space.

Live-Variable Analysis

This is a common optimisation technique for compilers that can directly be applied to model checking. Multiple variables can share the same memory location if they are not used at the same time. A variable is "alive" if a value assigned by a declaration is used by a subsequent statement (definition-usage-pairs). The effect of this optimisation technique on model checking depends highly on the structure of the source code but it will always shrink the state space and improve performance, unless the unlikely case occurs that no variables can be reused. This optimisation technique is also used to remove unused variables.

Statement Concatenation

The basic idea is to combine as many C statements as possible into a single SAL block, thus reducing the number of transitions to be executed by the model checker. If a model contains two C statements in each transition it requires only half the number of transitions compared to a model of the same program that contains only a single statement in each transition. The prerequisite for this optimisation is that the variables in the C statements are independent.

Variable Range Analysis

As mentioned above, analysing the value range of a variable can be used to keep the number of bits used for their representation small (1 bit vs. 16 bits for boolean expressions). For this optimisation a semantic analysis is necessary. This applies not only for boolean variables but also for integer variables as the model checker does not limit the variable size to multiples of eight bits. For integer variables not used as booleans this might require assistance from the user or, preferable, annotations made by the code generator. The code generator will have this information from the MatLab/Simulink model in most of the cases.

Variable Initialisation

All variables contained in the model that are not input variables are uninitialised. The model checker can assign any value to them and therefore produces a large set of D I . Assigning initial values to these variables does not reduce the size of the state space |D| but speeds up model checking by reducing |D R |.

Dead Variable and Code Elimination

Since we are not interested in the data flow but only in the control flow, all variables that do not affect the control flow directly or through assignments to other variables can be removed. Even code segments that do not affect variables involved in the control flow can be removed, as long as we are not looking for test data to reach these paths. This optimisation has a direct impact on the state space since it reduces the number of variables.

Evaluation of Optimisation Techniques

The current version of our C to SAL conversion tool does not yet support all the described optimisations. The structure of the example optimisations had to be manually applied to the generated SAL model. As hand-optimising the generated SAL model is a laborious and error prone task we used a short example code for this experiment instead of our real case study. The C source code for the evaluation consists of 105 lines without comments and empty lines, four boolean and thirteen byte variables from which three can be substituted by "Reverse CSE", three are not affecting the control flow and three are not used at all.

Table 2 shows the impact of the individual optimisations on the simulation time and on the memory footprint of the model checker. The last column shows the number of simulation steps that were performed. All evaluated optimisation methods except "combination of subsequent statements" and "initialising of undefined variables" reduce the state space directly by reducing the number of bits used for variable representation. It can be seen that reducing the state space has the strongest impact, especially the variable range analysing. By default all variables created by our C to SAL translator are 16 bit signed integers and therefore the usage of 8 bit signed integers or booleans, which are expressed with a single bit, cuts down the bits used for variable representation down to less than the half. Combining subsequent statements reduces the number of necessary transitions to about 65% of the original value, thus the model checker can find the results faster. This is an explanation for the lower time effort but not for the smaller memory footprint. The smaller memory footprint seems to be based on internal optimisations of the model checker. Obviously, the SAL model checker can reduce the state space when transitions are combined in the model.

From other experiments we have seen that the simulation time and memory footprint rises exponentially with the number of variables. Therefore, we expect the effect of these optimisations to be even more significant with larger programs. On the other hand, all optimisations in this evaluation are done by hand. It is reasonable to expect the optimisations done by a tool not to reach the same quality as when done by hand. This will result in a little degradation of the optimisations.

Other projects researching model checking for ANSI-C programs that should be mentioned for the interested reader are CBMC [START_REF] Clarke | A Tool for Checking ANSI-C Programs[END_REF], the BOOP Toolkit [START_REF] Weißenbacher | An Abstraction/Refinement Scheme for Model Checking C Programs[END_REF], BLAST [START_REF] Henzinger | Lazy Abstraction[END_REF], SPIN [START_REF] Holzmann | The Model Checker Spin[END_REF], and SLAM [START_REF] Ball | Automatically Validating Temporal Safety Properties of Interfaces[END_REF].

Case Study

Mainly, we investigated the concepts of our approach on several real-sized industrial applications. The most important results we gained from this work have been incorporated in Section 2 and Section 3. However, due to intellectual property issues we cannot publish these applications. To provide a convenient view on the big picture of our approach, we use a case study that is a magnitude smaller but has a similar structure to the original application. Also an almost identical design process and the same employment background as the industrial applications is used.

Our case study is an automotive wiper control application. The controller inputs are a two-step speed selector (off, slow and fast) for the wipers, a button to switch on the water pump and an end position switch to indicate the neutral position of the wipers.

Figure 4. Case Study

The design flow is illustrated in Figure 4. We modelled the application in MatLab/Simulink . The Stateflow chart has 9 states, the complete MatLab/Simulink model contains around 70 blocks. Using the TargetLink code generator we created the application code automatically. The whole functionality is encapsulated in a single function wiper control. This function is subject to our analysis method.

We instrumented the application with instructions starting and stopping an internal cycle counter register. Basically, the code consists of nested switch and if statements. Using the generated test data we enforce the execution of particular paths and measure the execution time of each case statement block.

Then the application is compiled and linked for the Motorola HCS12 platform and uploaded to the evaluation board. To enforce our test data on the input parameters and the state of the application we use the glue code functionality of MatLab/Simulink and TargetLink involving minimal user interactions for the transfer of the obtained execution time values.

Due to the small input space we could also evaluate the WCET to 250 cycles in exhaustive end-to-end measurements. But we partitioned the application so that each case block equals one PS and calculated a WCET bound of 274 cycles using the measured execution times and a simple timing schema approach. We did not apply any optimisations like semantic analysis or considering hardware effects to obtain this level of quality. One advantage of our method is that even if no semantic analysis is attached to the analysis process, many semantic dependencies are covered implicitly by the systematic partitioning.

Conclusion

In this paper we presented the results of the application of our measurement-based WCET analysis method described in [START_REF] Kirner | Measurement-Based Worst-Case Execution Time Analysis using Automatic Test-Data Generation[END_REF].

We have shown that it is possible to reduce the high complexity inherent in real-sized application code by applying a simple partitioning algorithm (Section 2).

We showd how model checking can efficiently be used to generate test data to execute individual paths of an application and can guarantee that test data patterns can be found to reach all feasible paths. This method can be used for testing because various structural code coverage criteria may be satisfied using this approach. Driven by the huge state spaces arising from the analysis of complex applications we introduced a number of new highly efficient optimisation techniques and presented a detailed evaluation of their capabilities.

Finally, we investigated a number of real automotive applications (Subsection 2.3) and illustrated the complete application of the WCET analysis method in a clearly arranged case study (Section 4).

Table 1 . Measurement effort with different path bound

 1

	1	int main () {
	2	int i;		start
	3	printf1 ();
	4	printf2 ();		4
	5 6	if (i ==0) {		9
	7	printf3 ();	11	13
	8	if (i ==0) {
	9	printf4 ();	14
	10	} else {
	11	printf5 ();	15
	12	}
	13	}		16
	14	if (i ==0)
	15	{		18
	16	printf6 ();
	17	printf7 ();	21
	18	}
	19	printf8 ();		end
	20	}
		Figure 1. Example listing with CFG
		Bound b Instr. Points ip Measurement m
		1	22	11
		2	16	9
		3	16	9
		4	16	9
		5	16	9
		6	2	6
		7	2	6

b 6, 3, 4, 5 need not to be instrumented (this reduces ip by 4 * 2 = 8), but the PS between node 4 and 15 is instrumented by 2 instrumentation points. Thus, we get ip = 22 -8 + 2 = 16. The number of measurements equals m = 11 -4 + 2 = 9 in this case. Finally, when the path bound is increased to 6, all paths in the function are covered by measurements. In this case, only two instrumentation points and 6 measurements are necessary.

Table 2 . Impact of optimisations on model check- ing time and memory usage

 2

	optimisation technique	simul. time [s]	memory use [kb] steps
	unoptimized	283.4 229,360 28
	all optimisations used	2.2	26,580 13
	Variable Initialisation	172.7 173,334 28
	Variable Range Analysis	12.7	59,492 28
	Reverse CSE	25.3	71,620 26
	Statement Concatenation	22.5	61,444 18
	Dead Variable Elimination	44.2	99,444 28
	Live-Variable Analysis	10.8	41,856 28

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

When using "intelligent" instrumentation, this number might be considered to be 500/2 + 1 =

by fusing two consecutive instrumentation points.

* This work has been supported by the FIT-IT research project "Model-based Development of distributed Embedded Control Systems (MoDECS-d)".


Pierre Guillot
email: guillotpierre6@gmail.com

Camomile: Creating audio plugins with Pure Data

Keywords: Pure Data, Plugin, DAW, VST, Audio Unit 1 Introduction

Camomile is an audio plugin with Pure Data embedded for creating, with patches, original and cross-platform audio plugins that work with any digital audio workstation that supports VST or Audio Unit formats. This paper presents an overview of the current functionalities of Camomile and the possibilities offered by this tool. Following this presentation, the main lines of future development are exposed.

in many prototypes that have preceded the current version of the plugin. This entire endeavour, the many functional specifications that have been defined, the major issues that have been encountered -such as support for multiple instances and multithreading in Pure Data, and linking Pure Data with the plugin -, the different solutions that have been proposed and the choices that have been made are all presented in detailed in [2] [START_REF] Puckette | Using Pd as a score language[END_REF] . As most of the technical barriers have been broken down, the main goal of this project is currently to offer a tool that can compete with standard plugins. Hence, following an overview of the many features already offered by Camomile, the paper exposes the remaining work that is needed to complete this plugin, and the perspectives of development.

In practice, Camomile can be viewed as a metaplugin: a plugin that generates other plugins. To clarify this presentation, the term "meta-plugin" will be used for this plugin -which embeds Pure Data; while the resulting plugins, containing the meta-plugin and patches, and can be used in digital audio workstations will simply be called "audio plugins". Thus, this presentation of Camomile is organised along two distinct but complementary axes. The first axis is focused on the creation of the audio plugin using the meta plugin: defining its functionality, creating patches, setting up features and so on. The second axis focuses on using the audio plugins: support by digital audio workstations, graphical interfaces and so on. Nevertheless, to offer a clear understanding of the defining aspects of each axis, this presentation is inverted. First, audio plugins usage is presented to highlight the features offered to the final user. Secondly, a large set of the features which can be implemented during the creation process will be shown. Following this presentation, future developments of Camomile and its general perspectives will be exposed.

Using plugins

Before presenting the different features available to create audio plugins, it seems necessary to introduce what is ultimately an audio plugin created with Camomile and how this audio plugin appears to the user. Indeed, the architecture of the audio plugin generated with Camomile is a bit particular, and its approach favours sharing patches, abstractions and other documents to be used in conjunction with the meta-plugin to generate plugins, rather than directly sharing audio plugins -mainly because the audio plugins are associated with specific formats and operating systems while the original documents are free from these restrictions, so this approach gives users more freedom. So understanding the architecture of an audio plugin and the result in digital audio workstations will allow users to get a better grasp of the process of creating plugins.

Generating and loading plugins

The flexibility and the dynamic aspect of the Camomile approach makes it a tool noticeably different from standard plugins. Indeed, the binary files offered in the distribution and the metaplugins, are not designed to be used directly within a digital audio workstation [START_REF] Torres Porres | Cloning Max/MSP Objects: A Proposal for the Upgrade of Cyclone[END_REF] . They must be used to set up the bond between the digital audio workstation and patches in order to generate the new audio plugins (see Figure 1). In practice, building an audio plugin with Camomile simply requires associating one of the meta-plugins provided by the distributionaccording to the desired format and the type of plugin [START_REF] Bukvic | Meet the Cat: Pd-L2Ork and its New Cross-Platform Version "Purr Data[END_REF] -to a main patch and a set of additional and complementary contents -textual description of the audio plugin, abstractions, images and so on. Specifically, the operation consists in renaming the meta-plugin according to the main patch and also consists in respecting a certain hierarchy of the relative paths of the different files by creating a bundle8 . Once this associated bundle is installed in the appropriate directory9 , the audio plugin is recognised by the digital audio workstations and is supported in the exact same way it would had been if compiled in a conventional manner (see Figure 2)10 . The digital audio workstation then offers the ability to load one or more instances of the plugin and interacts with them in a conventional way with operations such as creating automations for the parameters, saving and recalling presets and so on.

User interfaces

Apart from the native representation of the digital audio workstation, which usually offers generic interfaces to represent and control parameters, this plugin has its own graphical interface. This window displays a representation of the main patch that potentially includes sliders, buttons, comments, or other user interface components that are available in Pure Data (see Figure 2). This window makes it possible to represent the sound engine and interact with it, and also to communicate with the plugin. As will be shown later, the graphical user interfaces of the patch can be associated to parameters or specific actions like displaying a dialogue window to open or save files. In the upper-left corner of the interface, a button representing a chamomile flower is used to display an auxiliary window with three tabs (see Figure 3). The first tab corresponds to a console relatively similar to the one offered by Pure Data. This console receives the messages sent via the object print, the internal warnings of Pure Data -when an abstraction is not found for example -but also additional information related to the operation of the meta-plugin to facilitate debugging the patches. The console also allows you to copy, delete and filter messages according to their importance. The second tab displays information defined by the creator of the patch such as a description of the operations and how to use the plugin but also information related to credits or the plugin version. Finally, the last tab displays information related to Camomile, including legal information and credits related to different dependencies such as Pure Data, libPD 11 [3] and JUCE 12 .

Creating plugins

Building a digital audio plugin with Camomile requires proper communication between the patch -the core of digital audio processing -and the digital audio workstation through the meta-plugin. For this purpose, Camomile offers several interfaces to use and handle a wide range of the 11 libpd is wrapper that turns Pure Data into an embeddable audio library libpd.cc (accessed February 2018).

12 JUCE is an application programming interface oriented towards digital audio signal processing distributed by ROLI company juce.com (accessed January 2018). usual features of digital audio plugins, such as parameters management, reading information from the play head, or creating the graphical user interface. These interfaces cover two aspects of plugin creation: properties definition for the plugin -such as its ability to handle MIDI events or the number and nature of its parameters -and communication between the patch and the digital audio workstation through the meta-plugin -so that the digital audio workstation or the plugin can interact with the patch and reciprocally the patch with the digital audio workstation -for example, to send and receive digital audio signals but also MIDI events, or to control parameters.

Plugin properties definition

To ensure optimal functioning within digital audio workstations, audio plugin properties are defined using a text file named after the metaplugin and the main patch 13 . This properties file follows a syntax relatively similar to the FUDI 14 protocol where each line corresponds to a new statement and ends with a semicolon. So each statement can be used to define or to complete a feature or a property of the plugin. In order to ensure the proper functioning of the plugin, the console displays a warning if some properties have been wrongly defined, duplicated or omitted. Although in practice there is no hierarchy, these properties of the plugins can be organised according to categories.

First, properties are used to define general information, which is needed to generate the audio plugin and for it to function properly in digital audio workstations; such as the type of the plugin -to inform the user which meta-plugin to use for generating the plugin 15 -or the compatibility number -that corresponds to the version of the plugin with which the patch has been created and that is used to ensure compatibility with the patch 16 . 13 The documentation offers a full explanation on how to create and to use the properties file.

14 FUDI is a network protocol invented by Miller Puckette for Pure Dat a en.wikipedia.org/wiki/fudi (accessed February 2018). 15 The types can be effect or instrument and if the meta-plugin is not coherent with the type defined in the properties file, then the console displays a warning. 16 If the version of the meta-plugin used is inferior to the compatibility version, then the console displays a warning.

Properties can also be used to activate extra functionalities that are originally deactivated for reasons of efficiency, for example if the audio plugin needs to handle MIDI events, play head information, or key event.

An important part of the options is focused on audio signal processing, like latency, which is implied by the plugin when using an FFT for example, or audio tail length -the time during which the output still produce audio after the input has been stopped -for reverberation effect for example. But the main audio property defines the audio buses supported by the plugin -the audio input and output configurations. The different audio plugin formats support dynamic audio buses layout, as well as multichannel and side-chains. Camomile offers a syntax that helps using these features. Thereby, an audio plugin can support several layouts of multichannel buses, for a sound spatialisation plugin for example, or the enabling or disabling of side-chains, for a compressor for example, so the process of the patch can be adapted depending on the buses layout submitted by the digital audio workstation 17 .

Another important aspect of an audio plugin is related to the control protocol of its state by the digital audio workstations using parameters. A parameter represents one or several aspect of the audio engine with a numerical value -that can be saved, restored, automated, etc. by the digital audio workstation. Camomile offers the possibility to create highly-developed parameters with names, labels, ranges of values, steps and so on to improve their use, their representation and their meaning.

At last, properties are used to define additional attributes which are not necessary for the proper functioning of the plugin, but which can be essential to its ease of use, such as the description displayed by the plugin in its tab on the auxiliary window, the reference to an image file that the plugin displays as background of the graphical interface or an option to automatically reload the 17 All the audio buses layouts supported by the audio plugin must be defined at the first loading, so to support dynamic changes but also some specificities such as extra buses for side-chaining, this property must be predefined. More complex cases, like when the additional buses configurations depend on the main bus configuration, still need to be investigated. Furthermore, future versions could support a text description of the buses, like quadraphonic or ambisonic, to improve the specification of the configurations accepted by the plugin.

patch when it has changed -useful during the creation process.

Communication between the plugin and the patch

Communication between the patch and the digital audio workstation through the meta-plugin is, for its part, ensured via a set of conventions and practices. First of all, the messages sent and received by the meta-plugin to and from the patch are synchronised sequentially to the audio thread depending on an order defined arbitrarily 18 . Overall, the meta-plugin first sends its messages, such as parameter values or MIDI events, then it processes the patch's digital audio chain, and finally it retrieves the messages sent from the patch to its address 19 .

As defined by libpd, in a similar way to the applications PdParty or PdDroidParty, most of the communication can be handled within the patch using native objects: the objects adc~ and the dac~ for the audio signals 20 , the objects notein, noteout, ctlin, ctlout and so on for the MIDI events and the objects key, keyup and keyname for the keyboard events. Furthermore, using a 'bus' receiver makes it possible to retrieve information about the current audio buses layout of the plugin when the audio starts -for example, to adapt the audio process. Using a 'play head' receiver during processing can be used to retrieve information such as tempo, time signature of the current bar, current position of the play head and so on, which could be indispensable for some synthesisers. 18 Even if each Pure Data instance -each meta-plugin -can run in a separate thread, an instance can only be modified by only one thread, otherwise the behaviour is undefined and so potentially different from the one offered by the Pure Data application. 19 The specific order of each message according to its type is fully explained in the documentation. 20 In order to use directly the patch as an abstraction within the Pure data application, replacing the objects adc~and dac~ by the objects inlet~ and outlet~ has been considered. Nevertheless, this solution didn't seem desirable because it prevents to receive or to send the audio signals from inside subpatches or abstractions and it makes more complicated the dynamic patching that could be useful to adapt the process to the audio buses layouts submitted by the digital audio workstations. Furthermore, the implementation of the m e t a -p l u g i n b e c o m e s m u c h m o r e c o m p l e x implementation especially to manage the audio block size in the main patch that would be no more necessarily predefined.

The patch is also used to define the plugin's graphical user interface. The bounds of the patch's visible area within the plugin interface is defined by the properties of the patch when using it as a graphical abstraction 21 . The graphical objectssuch as the number box, the slider, the comment and so on -inside the area will be recreated by the plugin's interface and directly linked to their original object in such a way that no additional operation is necessary to communicate with the patch via the plugin (see Figure 4). Inspired from the approach defined in PdParty, the plugin offers a replacement for the native Pure Data mechanisms such as the one offered by the objects openpanel and savepanel by displaying a dialog window to select files from the disk. 21 The graphical abstractions are activated with the Graph-On-Parent option. 22 A similar mechanism has been implemented to display the floating window of the object array. And the same feature is considered for the object text.

Moreover Camomile makes it possible to completely and dynamically redefine the graphical interface by changing its size, the objects and so on -a useful feature used to adapt the interface to the modes and requirements of the audio plugin (see Figure 5).

A specific aspect to the implementation of audio plugins is parameter management. Parameters values can be received using a 'param' receiver. But one could also want to modify the value of a parameter with the graphical interface -to record automations for example. This operation requires first to notify the digital audio workstation that the parameter will change, then to change the valueonce or several times -and finally to notify the digital audio workstation that parameter modification has ended. If there are several graphical user interfaces and several parameters, these transactions become complicated to implement. Nevertheless the distribution offers a set of abstractions which can be directly connected to graphical objects to facilitate the setup of such mechanisms (see Figure 6). At last, when saving the digital audio workstation project or creating a new program, the meta-plugin automatically stores parameter states in an XML file. In addition, Camomile offers a mechanism to save and recall additional data via the patch that can be represented by parameters such as a system path or the content of an audio buffer.

With all these functionalities, Camomile offers the ability to create complex audio plugins with a large set of advanced features. Nevertheless, many developments can still be considered.

First of all, some native features of Pure Data relative to the graphical user interfaces are missing or can be improved, such as the implementation of the graphical object VU-meter or the improvement of the rendering of the graphical object labels. In order to get closer to standard plugins, it would be interesting to investigate the use of external images, which would replace drawing the graphical objects -using an image for the background of the object and one or more images for the foreground depending on the type of interface, it would be really easy to customise its representation. Another approach to offer more possibilities would be to implement the graphical part of the data structure of Pure Data [5], to draw and interact with more personal and original interfaces.

Support for external libraries is also very in demand by users. This feature could be a great improvement, this way someone could use an external as the audio processor of the pluginoptimizing the processes -and the patch as the interface with the meta-plugin and the digital audio workstation. Unfortunately, dynamic library loading seems to be restricted by the way Pure Data is embedded inside the meta-plugin 23 and by the fact that some of them are not directly compatible with multiple instance support 24 . Thus, direct integration of the most widespread libraries like the Cyclone [6] 25 or the Zexy 26 libraries inside the plugin is considered. Nevertheless, this requires checking the compatibility of all objects and these dependencies could make Camomile difficult to maintain 27 . 23 The reason of this restriction still need to be investigated. 24 If a library goes beyond the 'public' API of Pure Data and uses internal structures that deal with the multiple instance support, some problems may occur. 25 github.com/porres/pd-cyclone (accessed March 2018). 26 The Zexy library is developed by IOhannes m zmölnig puredata.info/downloads/zexy (accessed March 2018).

27 Using a monolithic approach by including the libraries [Bukvic & al., 2017] is one of the causes of the abandonment of the Pure Data variant, Pd-extended, puredata.info/downloads/pd-extended (accessed January 2018) originally maintained Hans Christoph Steiner.

Offering a version of the plugin in the LV228 format is also considered, however the differences with the VST and Audio Units formats raise compatibility problems that still need to be explored.

Figure 1 :

 1 Figure 1: Schematic operation of the generation of an audio plugin from a Pure Data patch and the meta-plugin Camomile.

Figure 2 :

 2 Figure 2: Representation of the graphical interface of the plugin AlmondOrgan, given as an example with Camomile, and generated from the patch.

Figure 3 :

 3 Figure 3: Auxiliary window of a plugin named Dummy illustrating the use of the console and the different types of messages.

Figure 4 :

 4 Figure 4: The part of the patch Castafiore that defined the graphical interface of the eponym plugin.

  22

Figure 5 :

 5 Figure 5: An example of a patch that illustrates the dynamic graphical interface of the plugin.

Figure 6 :

 6 Figure 6: An example of a patch that shows how to link three graphical objects with three parameters. The abstractions param.get and param.set manage respectively the getting and the setting of each parameter and the abstraction param.change manages the global distribution of the messages within the patchs.

The publication also presents the context in which this project took place and in particular the related projects such as PdVST and PdLV2 but also the parallel projects like PdDroidParty and PdParty[START_REF] Wilcox | PdParty: An iOS Computer Music Platform using libpd[END_REF].

In practice, the digital audio workstation can nevertheless load the meta-plugins but without any patch, and so without any audio engine, they are useless.

The distribution contains meta-plugin for each format -VST2, VST3 or Audio Unit -and each type of plugin -effect or instrument.

On Linux and Windows, the meta-plugin and the patch must be placed in the same folder. On MacOS, all the files must be placed in the OS specific bundle of the plugin. These operations are presented step by step in the documentation of Camomile.

The installation path of a plugin may depend on its format, the operating system or the preferences of the digital audio workstation. The documentation of Camomile helps to carry out this operation.

This feature presented in detail in[START_REF] Guillot | Camomile, Enjeux et Développements d'un Plugiciel Audio Embarquant Pure Data[END_REF] ensures that the digital audio workstation manages each plugin created with Camomile independently, thus avoiding problems related to the management of presets or parameters but also to the sharing of projects and plugins.

The LV2 format by D. Robillard is the successor of the LADSPA plugin format lv2plug.in/ns (accessed March 2018).

Acknowledgements

The author would like to thank the whole community of Pure Data and libpd developers, especially Miller Puckette and Dan Wilcox, for their advice and explanations as well as the users of Camomile for their great feedback and suggestions. The author would like to also acknowledge the CICM and especially Alain Bonardi and Eliott Paris for their interest in the project, their comments and their advices.

The binaries and sources are available on the Github repository github.com


Brian Hole

Francesco De Virgilio

Chealsye Bowley

Shared Infrastructure for Next-Generation Books: HIRMEOS

A central goal of HIRMEOS is to better integrate open access books with the open science ecosystem, in particular helping to increase the visibility and value of work from the social sciences and humanities (HIRMEOS 2018). Its wide-ranging scope includes building prototypes and ongoing systems to provide full integration with authentication and interoperability services (DOIs, ORCiD and FundRef), content enrichment services (INRIA N(E)RD), dissemination platforms (DOAB), a new peer review certification platform, annotation services (hypothes.is), and usage and alternative metrics.

A key aspect of this project is its focus on building fully open source, shared infrastructure. This is not simply due to altruistic community principles (though these are implicit), nor a matter of checking a box to qualify for funding, but also a logical and critical commercial decision by the nonprofit and for-profit project partners involved. There is a cultural change underway within the open access movement for shared and open infrastructure. The Collaborative Knowledge Foundation's PubSweet project (Coko Foundation 2018) for example sees commercial open access publishers such as Ubiquity Press, ELife and Hindawi working together to produce the next generation of fully open source journal publishing software, using best practices in collaborative open source development (see [START_REF] Hyde | The Cabbage Tree Method: Open Source Collaborative Product Development[END_REF]. The rationale is that the publishers involved share the cost (and risk) of developing core systems that they all require, and are able to benefit from more cost-effective, up-to-date and tailored software than they would otherwise have had access to through traditional suppliers. Risk is further lowered in that key systems remain shared rather than being potentially acquired by larger market players that may not be equally incentivized to retain certain aspects, such as open source code or open access functionality. These concerns are shared more broadly by the library community as well, as articulated recently for example in the proposal by David Lewis of the University of Indiana [START_REF] Lewis | The 2.5% Commitment[END_REF]) that libraries contribute 2.5% of their budgets towards shared open infrastructure.

HIRMEOS aims to play this role with shared infrastructure for book publication, equally benefiting for-profit publishers such as Ubiquity Press alongside non-profit ones such as EKT Open Book Press, OpenEdition Books, Open Book Publishers and Göttingen University Press and OApen. The following will focus on the Ubiquity Press led annotation and altmetrics deliverables of the project as examples.

User-generated annotation (as opposed to machine-generated enhancement) has been described as a "scholarly primitive" activity [START_REF] Unsworth | Scholarly Primitives: what methods do humanities researchers have in common, and how might our tools reflect this? Symposium on[END_REF] embedded throughout the scholarly lifecycle. As consumption of books moves online it is therefore essential to enable such fundamental activity if users are to adopt new platforms. At the same time such activity is naturally useful to measure if we are interested in the degree to which a book is being truly used within that lifecycle.

Previous attempts to integrate annotation with online systems were not entirely successful, largely due to limitations of browsers and the web (Bradley 2007). This has since changed with the introduction of W3C standards for web annotation (W3C 2017) enabling a range of new annotation services such as hypothes.is and PaperHive to be reliably used across the web.

The annotation work in HIRMEOS involves ensuring that the hypothes.is system is integrated with all of the project partners' products, providing for a consistent user experience across all platforms. Among other technical challenges, this involves ensuring that hypothes.is is able to work with the EPUB readers used by these platforms, as this often involves iteratively embedded objects that are difficult for such software to access. Metrics for annotations made will be collected and stored by the metrics system also being developed as part of the project.

Altmetrics, which aim to look beyond traditional measures such as peer review, citation counts and Impact Factors [START_REF] Priem | Altmetrics: A manifesto[END_REF] have become increasingly salient within STEM publication within recent years [START_REF] Warren | The Rise of Altmetrics[END_REF][START_REF] Piwowar | Value All Research Products[END_REF]. The fact that they are now increasingly used in academic assessment programs leads many to worry that HSS scholars are at a disadvantage in regard to how their work is measured and thereby valued (e.g. [START_REF] Hammarfelt | Interdisciplinarity and the Intellectual Base of Literature Studies: Citation Analysis of Highly Cited Monographs[END_REF]. Altmetrics are therefore an important service to be provided by HIRMEOS, with the aim of enabling the use and impact of open access books to be assessed in a comparable way to works from other disciplines.

Through the project a metrics service based on that already used by Ubiquity Press is currently being developed (HIRMEOS 2017) and will be integrated with all partner platforms in order again to provide a familiar, consistent and comparable experience for users. The system makes use of DOIs to produce metrics for citations, as well as altmetrics from Twitter, Facebook, Wikipedia and hypothes.is. The publishers individually register their DOIs with the service hosted on Ubiquity Press servers (initially, just loading a CSV). The service then harvests metrics for those DOIs on a daily basis and these can be queried through an open API or displayed on each platform in a fully consistent way in time series, through a JavaScript widget embedded on their respective websites. Wherever possible the system makes use of existing open infrastructure (e.g. Crossref Event Data), and community-expected standards (e.g. COUNTER compliance).

Both services are being developed using the Django web framework and the Python programming language (respectively versions 2 and 3.6). flexible set of plugins, each one targeting a specific metrics source. Plugins are intended to be relatively small in size and are not tied to any specific database structure: their scope is limited to talking to a specific data source, gathering the relevant data and handing the results to the altmetrics service after reshaping them consistently. This allows any contributor to add a new plugin in order to integrate a new source. A generic demo plugin is available in the code base to make it easier for developers to create new plugins. Altmetrics related to annotations are harvested by a dedicated annotation plugin, which is itself part of the altmetrics service.

One of the challenges of the project is the wide variety of sources to be aggregated in order to gather significant statistics. In order to make the retrieval easier and more structured, all metrics are built around the DOI as the unique identifier of the document. This involves resolving the different identifiers used by different services to the same DOI. In order to do so, the altmetrics service relies on the registration of the DOIs by the HIRMEOS partners; the annotation plugin relies on the Crossref Event Data service (which in turn integrates well with hypothes.is).

Regarding the annotation plugin specifically, partners will be asked to implement standard Dublin Core meta tags in their pages; any annotation created by the reader on a page will be registered by hypothes.is using the URL of the page, and the Crossref Event Data service will take care of associating the two, making annotations available on a per-DOI basis.

The most complex aspect the altmetrics service is dealing with the large amount of DOIs it will be required to collect metrics for. A scalable approach has therefore been adopted, turning any data gathering process into an asynchronous task that is handed to a queuing system (RabbitMQ). The queuing service distributes tasks to all the available workers, which perform the actions of querying the data source and collecting the results. Each task is worked on independently from the others, and the number of workers connected to the queue can be automatically scaled based on the number of DOIs registered in the service, thus avoiding any performance degradation.

The altmetrics service has been designed with data portability in mind and aims to provide a standard way to add and extract data to and from the project. In this context, the REST API is one of the key features of the service, enabling programmatic access to the metrics. Using well known strategies for API caching (e.g. last-modified HTTP header), the API provides fast access to the metrics. The API will be primarily used by the web widget integrated in the partners' websites to show metrics, but can also be used for producing visualizations or other statistical purposes by the partners.

Currently, the only way provided to register new DOIs into the service is a manual CSV upload, but there are plans to extend the above-mentioned API interface to include DOI registration, allowing partners' publishing platforms to POST to the altmetrics service every time a new DOI is registered.

Given the number of different components the service is built on, and in the spirit of lowering the entry barrier for new developers, a Docker-based deployment approach has been chosen to run the service in production environments. Configuration files to build the Docker container are provided as part of the open source codebase, enabling any developer to have a fully working and configured altmetrics service in minutes. Other configuration files provided with the project (Compose stackfile) allow developers to create a fully functional environment including all the back-end services needed to run the project (RabbitMQ, Redis cache, Celery workers). Some practical limitations of the project are related to the frequency with which data sources are to be queried and the possibility that these could be limited by throttling. This scenario could become likely with the growth in the number of DOIs registered in the service. Currently, a configuration internal to the altmetrics service is used to schedule the queries, which are performed daily for all DOIs. As the service is still under active development, tests will be performed to decide what the most optimal frequency is. Some of the measures which could be taken to mitigate the throttling issue are to query data sources for multiple DOIs in a single request (where possible), or use remote agents running on separate hardware instances (having different IPs), distributing the data gathering workers in order to avoid queries from the same IP (the queuing strategy makes this approach very easy). As Facebook discontinued API access to public content [START_REF] Facebook | Public Feed API[END_REF]; overcoming this issue will require an investigation of the different possibilities, which has not been conducted yet.

Backend and integrations tests are being developed as part of the project. Testing is a standard practice in the software development process, but it becomes even more important when the service relies on integrations with external data providers. At completion, each data source plugin will include test fetching data from the data provider, ensuring that the code is still able to deal with any change in the data provider API. The project is currently hosted on HIRMEOS GitHub's repository, and tests are run automatically on the Ubiquity Press internal continuous integration service before release of any new features, which ensures that any change in external providers is addressed before the release.

The addition of annotations as an altmetric is a key highlight of the project. As mentioned above annotation is a fundamental activity within scholarship, yet it is not well measured or reported. It can be argued that it is more widespread and deeply practiced within HSS disciplines in particular, as books often require a longer and deeper engagement from researchers than do research articles, necessitating more in depth note-taking and receiving less immediate citation. It is hoped that by providing an altmetric to measure this activity, the metrics of books will be boosted in the longer term, enabling them to be better compared to STEM outputs that to date have been more easily and immediately assessed. A potential future expansion of the service may also enable the system to achieve one of the original goals of altmetrics as envisioned by [START_REF] Priem | Altmetrics: A manifesto[END_REF], i.e. to "look beyond counting and emphasize semantic content", based on the location, frequency and content of the annotations.

BIBLIOGRAPHY

  work being done to provide shared altmetrics services, including reporting on annotation activity. INDEX Keywords: monographs, metrics, altmetrics, annotation, open source software AUTHORS BRIAN HOLE Ubiquity Press, United States brian.hole@ubiquitypress.com (corresponding author) FRANCESCO DE VIRGILIO Ubiquity Press, United Kingdom francesco.devirgilio@ubiquitypress.com CHEALSYE BOWLEY Ubiquity Press, United States chealsye.bowley@ubiquitypress.com Shared Infrastructure for Next-Generation Books: HIRMEOS ELPUB 2018

The altmetrics service consists of a shared set of functions (dealing with data aggregation, notifications, the API and some database-related tools) which provides a solid ground to a


Alban Bazile
email: alban.bazile@mines-paristech.fr

E Hachem

J C Larroya-Huguet

Y Mesri

Variational Multiscale error estimator for anisotropic adaptive fluid mechanic simulations: application to Navier-Stokes problems

Keywords: CFD, VMS, Error Estimator, Mesh Adaptation, Navier-Stokes . . . . . . . . . . . . cavity problem in 3D . . . . . . . . .

come

1. Introduction

The incompressible Navier-Stokes equations in the Variational

Multi-Scale framework

The incompressible Navier-Stokes equations

To fix the notations, let Ω ⊂ R d be the fluid domain, where d is the space dimension, and ∂Ω its boundary. The strong form of the incompressible Navier Stokes equations reads:

ρ (∂ t v + v • ∇v) -∇ • σ = f ∇ • v = 0 ( 1
)
where t ∈ [0, T ] is the time, v(x, t) the velocity, p(x, t) the pressure and ρ the density. The Cauchy stress tensor for a Newtonian fluid is given by:

σ = 2µ ε(v) -p I d , (2)
with I d the d-dimensional identity tensor and µ the dynamic viscosity. In order to close the problem, Eq. ( 1) are subject to the homogeneous Dirichlet boundary conditions.

The weak form of problem (1) combined with (2) is obtained by multiplication of a test function and integration by parts. Let H 1 (Ω) be the Sobolev space of square integrable functions whose distributional derivatives are square integrable, and let V ⊂ [H 1 (Ω)] d be a functional space properly chosen according to the boundary conditions. Finally, let Q = q ∈ L 2 (Ω) : Ω q = 0 . By denoting ( • , • ) the scalar product of the space L 2 (Ω), the weak form of problem [START_REF] Ern | Éléments finis: théorie, applications, mise en oeuvre[END_REF] on ∂Ω reads:

     Find (v, p) ∈ V × Q such that: ρ [(∂ t v, w) + (v • ∇v, w)] + (2µε(v) : ε(w)) -(p, ∇ • w) = (f , w) , ∀w ∈ V (∇ • v, q) = 0, ∀q ∈ Q.
(3) where ρ and µ are the density and the dynamic viscosity, respectively.

The standard Galerkin approximation consists in decomposing the domain Ω into N el elements K such that they cover the domain. Therefore, the elements are either disjoint or share a complete edge (or face in 3D). Using a partition T h , the above-defined functional spaces V and Q are approached by finite dimensional spaces V h and Q h such that:

V h = {v h |v h ∈ C 0 (Ω) n , v h|K ∈ P 1 (K) n , ∀K ∈ T h } (4) Q h = {p h |p h ∈ C 0 (Ω) n , p h|K ∈ P 1 (K) n , ∀K ∈ T h } (5)
The Galerkin discrete problem consists therefore in solving the following mixed problem:

     Find (v h , p h ) ∈ V h × Q h such that: ρ [(∂ t v h , w h ) + (v h • ∇v h , w h )] + (2µε(v h ) : ε(w h )) -(p h , ∇ • w h ) = (f , w h ) , ∀w h ∈ V h (∇ • v h , q h ) = 0, ∀q h ∈ Q h .
(6) It is well known that the stability of the semi-discrete formulation requires an appropriate choice of the finite element spaces V h and Q h that must fulfill a compatibility condition [START_REF] Ern | Éléments finis: théorie, applications, mise en oeuvre[END_REF]. Accordingly, the standard Galerkin method using P1/P1 elements (i.e. the same piecewise linear space for V h and Q h ) is not stable. Moreover, convection-dominant problems (i.e. problems where the convection term v • ∇v is much larger than the diffusion term ∇ • (2µ ε)) also lead to a loss of coercivity in the formulation (3). This phenomenon manifests itself as oscillations that pollute the solution.

The Variational Multi-Scale formulation

In this work, we use a Variational MultiScale method [START_REF] Hughes | Multiscale phenomena: Green's functions, the Dirichletto-Neumann formulation, subgrid scale models, bubbles and the origins of stabilized methods[END_REF] which circumvents both the previously stated problems through a Petrov-Galerkin approach. The basic idea is to consider that the unknowns can be split into two components, a coarse one and a fine one, corresponding to different scales or levels of resolution. First, we solve the fine scales in an approximate manner and then we replace their effect into the large-scale equation. We present here only an outline of the method, and the reader is referred to [START_REF] Hachem | Stabilized finite element method for incompressible flows with high Reynolds number[END_REF] for extensive details about the formulation.

Basic principles of the multiscale approach

Let us split the velocity and the pressure fields into resolvable coarse-scale and unresolved fine-scale components: v = v h + v and p = p h + p . The same decomposition can be applied to the weighting functions: w = w h + w and q = q h + q . Subscript h is used hereafter to denote the finite element (coarse) component, whereas the prime is used for the so called subgrid scale (fine) component of the unknowns. The enrichment of the functional spaces is performed as follows:

V = V h ⊕V , V 0 = V h,0 ⊕V 0 and Q = Q h ⊕Q .
Thus, the finite element approximation for the time-dependent Navier-Stokes problem reads:

         Find(v, p) ∈ V × Q such that: ρ (∂ t (v h + v ), (w h + w )) Ω + ρ ((v h + v ) • ∇(v h + v ), (w h + w )) Ω + (2µε ε ε(v h + v ) : ε ε ε(w h + w -((p h + p ), ∇ • (w h + w )) Ω = (f , (w h + w )) Ω , ∀w ∈ V 0 (∇ • (v h + v ), (q h + q )) Ω = 0, ∀q ∈ Q.
(7) To derive the stabilized formulation, we split Eq. ( 7) into a large-scale and a fine-scale problem. Integrating by parts within each element, we obtain the so-called coarse-scale problem:

     ρ (∂ t (v h + v ), w h ) Ω + ρ ((v h + v ) • ∇(v h + v ), w h ) Ω + (2µε ε ε(v h ) : ε ε ε(w h )) Ω -((p h + p ), ∇ • w h ) Ω = (f , w h ) Ω , ∀w h ∈ V h,0 (∇ • (v h + v ), q h ) Ω = 0, ∀q h ∈ Q h .
(8) and the so-called fine-scale problem:

     ρ (∂ t (v h + v ), w ) K + ρ ((v h + v ) • ∇(v h + v ), w ) K + (2µε ε ε(v h ) : ε ε ε(w )) K -((p h + p ), ∇ • w ) Ω = (f , w ) Ω , ∀w ∈ V 0 (∇ • (v h + v ), q h ) Ω = 0, ∀q ∈ Q . ( 9
)
where ( • , • ) Ω represents the scalar product on the whole domain while ( • , • ) K is the scalar product on element K.

To derive our stabilized formulation, we first solve the fine scale problem (9), defined on the sum of element interiors and written in terms of the timedependent large scale variables. Then we substitute the fine scale solution back into the coarse problem (8), thereby eliminating appearance of the finescale while still modelling their effects. As in [START_REF] Hachem | Stabilized finite element method for incompressible flows with high Reynolds number[END_REF]; we recall here 3 important remarks/assumptions that have to be made:

• by considering the small scale velocity as bubble functions vanishing on the boundaries of the element, terms involving integrals over the element interior boundaries will be neglected,

• we neglect the second derivatives of the weighting function in the momentum residuals of (9),

• as the fine-scale space is assumed to be H 1 -orthogonal to the finite element space, crossed viscous terms vanish in (8) and (9).

The fine scale sub-problem

Under several assumptions about the time-dependency and the non-linearity of the momentum equation of the sub-scale system detailed in [START_REF] Hachem | Stabilized finite element method for incompressible flows with high Reynolds number[END_REF], the finescale solutions v and p can be written in terms of the time-dependent largescale variables using residual-based terms that are derived consistently. For all K ∈ T h , we have:

v | K = τ K R M p ≈ τ C R C (10)
where the momentum residual R M and the continuity residual R C are expressed as:

R M = f -ρ∂ t v h -ρv h • ∇v h -∇p h R C = -∇ • v h (11)
In this work, we adopt the definition proposed by Codina in [4] for the stabilizing coefficient:

τ K = 2ρ v h K h K 2 + 4µ h 2 K 2 -1 2 , ( 12
)
τ C = µ ρ 2 + c 2 v h K c 1 h K 2 1 2 (13)
where h K is the characteristic length of the element and c 1 and c 2 are algorithmic constants. We take them as c 1 = 4 and c 2 = 2 for linear elements. v h K is the coarse scale velocity norm on the element, defined by:

v h K = v 2 x,h + v 2 y,h (14)

The coarse scale sub-problem

Let us consider the coarse scale problem (8). Taking into account the assumptions prescribed in [START_REF] Hachem | Stabilized finite element method for incompressible flows with high Reynolds number[END_REF] and recalled in Section 2.2.1 for the fine scale fields, the large-scale system becomes:

     ρ (∂ t v h , w h ) Ω + (ρv h • ∇v h , w h ) Ω + (ρv h • ∇v , w h ) Ω + (2µε ε ε(v h ) : ε ε ε(w h )) Ω -(p h , ∇ • w h ) Ω -(p , ∇ • w h ) Ω = (f , w h ) Ω , ∀w h ∈ V h,0 (∇ • v h , q h ) Ω + (∇ • v , q h ) Ω = 0, ∀q h ∈ Q h .
(15) Then, integrating by parts the third term in the first equation and the second term in the second equation of (15) and substituting the expressions of both the fine-scale pressure and the fine-scale velocity of (10), the large-scale system reads:

     ρ (∂ t v h , w h ) Ω + (ρv h • ∇v h , w h ) Ω -K∈T h (τ K R M , ρv h ∇w h ) K + (2µε ε ε(v h ) : ε ε ε(w h )) Ω -(p h , ∇ • w h ) Ω -K∈T h (τ C R C , ∇ • w h ) K = (f , w h ) Ω , ∀w h ∈ V h,0 (∇ • v h , q h ) Ω -K∈T h (τ K R M , ∇q h ) K = 0, ∀q h ∈ Q h ( 16
) Finally, substituing the residuals of the momentum equation and developping all the additional terms, we obtain a modified coarse scale formulation expressed exclusively in terms of coarse scale variables. The new modified problem for linear tetrahedral elements can now be decomposed into four main term: the first one is the standard Galerkin contribution, the second and the third terms take into account the influence of the fine-scale velocity on the finite element components and the last term models the influence of the fine-scale pressure onto the large-scale problem. We finally get:

ρ (∂ t v h + v h .∇v h , w h ) Ω + (2µε ε ε(v h ) : ε ε ε(w h )) Ω -(p h , ∇.w h ) Ω + (∇.v h , q h ) Ω -(f , w h ) Ω + K∈T h τ K (ρ(∂ t v h + v h .∇v h ) + ∇p h -f , ρv h ∇w h ) K + K∈T h τ K (ρ(∂ t v h + v h .∇v h ) + ∇p h -f , ∇q h ) K + K∈T h (τ C ∇ • v h , ∇ • w h ) K = 0 ∀w h ∈ V h,0 , ∀q h ∈ Q h (17)
Compared to the standard Galerkin method, the proposed stable formulation involves additional integrals that are evaluated element-wise. These additional terms represent the stabilizing effect of the sub-grid scales and are introduced in a consistent way in the Galerkin formulation. They make it possible to avoid instabilities caused by both dominant convection terms and incompatible approximation spaces.

A posteriori error estimation on solution's subscales

In this paper, the first objective is to compute an a posteriori subscales error estimator for the incompressible Navier-Stokes equation. To do so, we will use two different approach. The first one is based on the computation of the stabilizing parameters proposed in the previous section. The second one however, is based on the building of high order bubble functions on the element.

Computation of the error estimator with the stabilizing parameters approach

The stabilizing parameter approach for the a posteriori error estimator computation consists in using the assumptions made in Section 2.2.2. In fact, the application of the VMS approach leads to an approximation of the sub-grid variables v and p using an explicit expression taking into account the residuals and the stabilizing parameters (see Eq. 10). Therefore, it is possible to compute an element-wise expression of the sub-grid variables.

Considering v , for all K ∈ T h , we have:

v | K ≈ τ K R M v | K ≈ τ K × (f -ρ∂ t v h -ρv h • ∇v h -∇p h ) v | K ≈ 2ρ v h K h K 2 + 4µ h 2 K 2 -1 2 × (f -ρ∂ t v h -ρv h • ∇v h -∇p h ) (18)
For here, we can compute 3 different type of norms for v | K . We denote these 3 norms L r with r = 1, 2, ..., ∞. In practice, as referred in [START_REF] Hauke | Variational multiscale a posteriori error estimation for systems: The Euler and Navier-Stokes equations[END_REF], it is recommend to take r = 1, 2. We thus get:

v L r (K) ≈ 2ρ v h K h K 2 + 4µ h 2 K 2 -1 2 × (f -ρ∂ t v h -ρv h • ∇v h -∇p h ) L r (K) v L r (K) ≈ 2ρ v h K h K 2 + 4µ h 2 K 2 -1 2 × (f -ρ∂ t v h -ρv h • ∇v h -∇p h ) L r (K) (19)
If we take, for example r = 2, we get:

v L r (K) ≈ 2ρ v h K h K 2 + 4µ h 2 K 2 -1 2 × |K|× 1 i N interp (f -ρ∂ t v h -ρv h • ∇v h -∇p h ) (x i
(20) where (x i ) 1 i N interp are the interpolation points of the element and N interp is the number of interpolation points.

In the same way, considering p we have:

p ≈ τ C R C p ≈ τ C × (-∇ • v h ) p ≈ µ ρ 2 + c 2 v h K c 1 h K 2 1 2 × (-∇ • v h ) (21)
Taking the L r norm, we get:

p L r (K) ≈ µ ρ 2 + c 2 v h K c 1 h K 2 1 2 × (-∇ • v h ) L r (K) p L r (K) ≈ µ ρ 2 + c 2 v h K c 1 h K 2 1 2 × (-∇ • v h ) L r (K) (22)
In the same way, taking for example r = 2, we get:

p L r (K) ≈ µ ρ 2 + c 2 v h K c 1 h K 2 1 2 × |K| × 1 i N interp (-∇ • v h ) (x i ) 2 (
23) where (x i ) 1 i N interp are the interpolation points of the element and N interp is the number of interpolation points.

Finally, we obtain two subscales error estimators v L r (K) and p L r (K) in the L r norm for the subscales variables v and p respectively. These error estimators are computed thanks to the stabilizing parameters τ K and τ C . Furthermore, they are both computed element-wise and can be used as such in mesh adaptation.

Computation of the error estimator with the high order bubbles functions

approach Another way to compute the a posteriori error estimates for the incompressible Navier-Stokes equation is by using the error analysis developed by Hauke et al. in [START_REF] Hauke | Variational multiscale a posteriori error estimation for systems: The Euler and Navier-Stokes equations[END_REF]. In this paper, Hauke et al. derive three different error estimators: the standard, the naive, and the upper bound. It is applied to multidimensional linear systems and in particular, to the incompressible Navier-Stokes equations. Therefore we will adopt the notation taking Y : Ω -→ R neq the solution vector with n eq the number of equations of the system (which coincides with the number of unknowns). In our case, in a 3D computation, we have:

Y(x) =     v x (x) v y (x) v z (x) p(x)     (24)
Using the variational multiscale method, as before, we introduce a sum decomposition of the exact solution Y(x) into the finite element solution (coarse scale) Y h (x) and the error (or subscales) Y (x). We do likewise for the weighting function. We have:

Y(x) = Y h (x) + Y (x) (25)
Then, the method consists first in the splitting of the subscales error into two component stemming from the element interior residuals and the boundary element residuals, namely:

Y (x) = Y int (x) + Y bnd (x) (26)
Using the triangle inequality, we can write for each component [START_REF] Hauke | Variational multiscale a posteriori error estimation for systems: The Euler and Navier-Stokes equations[END_REF]:

Y i (x) Y i, int (x) + Y i, bnd (x) (27)
Using the same assumptions than in Section 2.2.1 for highly convective regimes, and considering the small scale variables as bubble functions vanishing on the element boundaries, we can write:

Y i, bnd (x) ≈ 0 (28) Therefore, we have:

Y i (x) Y i, int (x) (29)
As referred in [START_REF] Hauke | Variational multiscale a posteriori error estimation for systems: The Euler and Navier-Stokes equations[END_REF] the naive approach concerning the a posteriori error estimates gives local efficiencies close to unity. Therefore, we choose this approach to estimate the error. According to Hauke et al., we have:

where B e 0 is a matrix residual-free bubble defined in [? ? ? ].

For example, if we take i = x, we get: v x, int (x) ≈ meas(K)

YR

  i, int (x) ≈ meas(K) 1/r j τ e Lr,ij R j (x) L ∞ (K) M,x (x) R M,y (x) R M,z (x) R C (x) ) 1/r B e 0 (x) Lr(K)

  1/r × τ e Lr,xx R M,x (x) L ∞ (K) + τ e Lr,xy R M,y (x) L ∞ (K) + τ e Lr,xz R M,z (x) (33)

Acknowledgments

This work was supported by Safran Aircraft Engines [CIFRE 2015/1348].


Tom Olyhoek

Barbara Porrett

Dominic Mitchell

The DOAJ Ambassador Programme: An Example Project for Promoting Cognitive Justice in the Global South

Introduction 1

The Directory of Open Access journals (DOAJ) was founded in 2003 as a list of good quality Open Access journals. What began as a list of a few hundred journals has grown into an index containing >11,000 journals. Although the DOAJ index already contains entries from many countries we felt an urgent need to expand it with more journals from the Global South. In our view this was a necessary step in order to continue to serve as the comprehensive global whitelist of trustworthy open access journals and as a comprehensive index of OA journals for authors, researchers, librarians and publishers [START_REF] Stenson | The development of Directory of Open Access Journals[END_REF]. Inclusion of these journals will serve to increase the visibility and access to scientific knowledge from the Global South. It will also serve to combat cognitive injustice. When local knowledge is less accessible and marginalized in the global scientific output by virtue of the pressure on scientists to publish preferentially in English language journals from the Global North, cognitive injustice occurs [START_REF] Hall | Decolonization of knowledge, epistemicide, participatory research and higher education[END_REF][START_REF] Piron | Justice cognitive, libre accès et savoirs locaux. Pour une science ouverte juste, au service du développement local durable[END_REF].

2

For this reason the DOAJ started the Ambassador programme in 2016. A team of scholars from the developing world (the Ambassadors) were trained to evaluate open access journals from their regions and to assist local publishers in meeting the requirements of good publishing practice. Other successful ambassador programs for the promotion of education and teaching had already been established by EIFL and COS (Center for Open Science). Additional organizations are seeking to set up their own programmes. To the best of our knowledge, the DOAJ initiative to employ ambassadors in the Global South for the promotion of open access publishing and the evaluation of local journals is unique.

With the help of the Ambassador programme, all questionable journals, many of from developing world regions [START_REF] Thomas | African academics are being caught in the predatory journal trap[END_REF][START_REF] Jones | Predatory publishing isn't the problem, it's a symptom of information inequality[END_REF], have now been removed from DOAJ. Many other journals were also removed, during a two year period, for not meeting the DOAJ criteria. During that time, all existing journals in the database were reevaluated using the newly developed set of criteria [START_REF] Adams | Directory of Open Access Journals introduces new standards to help community address quality concerns[END_REF][START_REF] Van Norden | Open Access web site gets tough: leading directory tightens listing criteria to weed out rogue journals[END_REF]Olijhoek et al., 2016). The Ambassadors and local voluntary editorial teams have been instrumental in completing this process successfully. In addition, their work has increased the coverage of open access journals from their respective regions in DOAJ. Currently Ambassadors and local teams are identifying the publishers of credible journals in their respective region, guiding them to meet the criteria of best publishing practice and encouraging these journals to apply for indexing in the DOAJ.

Setting up the Ambassador programme Selection

The project required Ambassadors to engage in the following tasks:

• Identify tools other than the DOAJ that assist in making informed decisions about where to submit articles for publication (based in part on the ThinkCheckSubmit initiative) and share case studies and examples gathered by DOAJ in over thirteen years of operation.

• Evaluate journals for inclusion in the Directory based on a set of criteria developed to identify and promote best publishing practice, transparency and high editorial quality. The criteria for inclusion in the DOAJ are an integral part of the application form (DOAJ Application Form, https://doaj.org/application/new, accessed 26 March 2018).

• Liaise with publishers and academics in their own countries/regions and advise them on the importance of best practice, transparency and high editorial quality.

• Promote OA publishing in the "Global South", as defined in an IDRC list of 85 countries in 10 regions with an Ambassador for each region. (Countries covered by each Regional Ambassador, DOAJ document, http://bit.ly/2DV2J5K, accessed 26 March 2018).

The IDRC list of countries and regions was broken down into 7 areas (Table 1-See bellow) based on the distribution of the 2,500 applications or re-applications from journals from developing countries in the DOAJ index at the start of the project. Candidates to serve as Ambassadors were identified from existing lists of contacts, crowdsourced from partner organizations and requested in a blog post announcement (IDRC grant to improve OA journals from the Global South, DOAJ Blog, http://bit.ly/2DTCT24, accessed 26 March 2018).

Twelve trustworthy, reputable and dedicated individuals were interviewed and identified to become DOAJ Ambassadors. Selection was based on experience, language skills and connectivity. Interviews were conducted online and references were then checked. The locations of the successful candidates resulted in an adjustment to the breakdown of regions to match the geographic distribution of the selected Ambassadors (Table 2-See bellow). Publishers, requesting that Russia be included in the programme. The President was impressed by the potential impact that such a project could have and wanted very much to see the same impact in Russia. As a result, three Russian Ambassadors also joined the programme with funding from their own organizations. **Indonesia and South Korea have been included in the Ambassador programme since 2017. After conducting training sessions in each country, four Ambassadors were selected from each region.

7

The DOAJ currently has 23 Ambassadors worldwide. Their positions and backgrounds are diverse: from PhD student to professor, a librarian to head of a university library, and from library and informatics specialist to senior manager in a publisher organization.

Equally, the ages of the Ambassadors range between 30 and 60. The Ambassadors were tasked with handling existing applications from their own countries/regions. They have communicated with those submitting applications to DOAJ, raised awareness around open access and open science and operated proactively as a "helping hand" for the applicants. Each Ambassador had a dedicated DOAJ team member allocated as their supervisor. The supervisor participated in continued training online and worked with the Ambassador in the processing of applications to ensure that they could carry out their duties effectively. The Ambassadors' performance was monitored via the DOAJ administration system which is used for all application-related transactions.

During the entire project, the DOAJ team have facilitated the exchange of experiences and challenges through regular online meetings with all Ambassadors.

Outreach

The Ambassadors collaborated with DOAJ staff to tailor generic presentations (often in local language) to meet local needs. These were presented by them at relevant events in their country or region. Opportunities for outreach were identified in collaboration with the Ambassadors and partner organizations (EIFL, ISSN, INASP etc.). These included publisher events, academic library events and events at universities and research institutions. Translation of relevant information pages of the DOAJ website and of flyers and posters was undertaken by Ambassadors in close cooperation with DOAJ staff. Having this information available in local languages proved enormously valuable to the work of the Ambassadors.

The Ambassadors have reached out to communities in their regions and general information has been pushed out via the various channels available-the DOAJ website and partner organizations like EIFL, Research for Life (R4L), ISSN, and social media channels (Facebook, Twitter, and Chinese social media platforms etc.).

The However, the scale of the increase and the number of promotional activities undertaken by the Ambassadors suggest that there is a positive correlation between the high growth rate of usage and the DOAJ Ambassador programme.

14 In addition, the DOAJ Ambassadors have made more than 100 contributions/ presentations at local conferences and events, where the knowledge they have acquired during the project was disseminated. DOAJ assisted, where needed, in creating presentations for the Ambassadors at regional conferences and assisted in writing papers/social media contributions from the Ambassadors. She has worked with institutions and organizations at a national and regional level in the training of students, teachers and researchers on issues regarding scientific publishing in Open Access. Ivonne is the DOAJ Ambassador for the region of Latin America.

Major achievements

-Events: 5 presentations, 10 talks and workshops.

-Applications: processed over 300 applications 15 A major lesson that the DOAJ team learnt from the Ambassador programme is the difficulties of explaining the concepts of open access to Ambassadors, and then by the Ambassadors to their local contacts. The team has also observed that where Ambassadors have worked with governments to increase awareness, the commitment to open access principles has been strengthened. For example:

1. After working closely with the DOAJ Ambassador Prof. Kamel Belhamel, the Algerian government has required open access publishing by all scientists at Algerian universities.

2. An Indonesian organization of professors and university lecturers called ADRI has been instrumental in recruiting Ambassadors for the country and for establishing contacts with the Indonesian government. The government recognizes journals listed in the DOAJ as accredited journals and Indonesian scientists can earn merits when they publish in these OA journals.

16 These examples illustrate the importance of making higher level connections either through the local DOAJ Ambassadors, or through organizations that have solicited collaboration with the DOAJ. To help increase awareness and the uptake of best practice even further, the DOAJ team developed an online resource, the DOAJ Best Practice Guide (http:// www.doajbestpracticeguide.org/. It provides information about best practice in scholarly publishing and guidance on to how to identify questionable publishing practices. This resource was developed with existing and new information from the Ambassador programme. The resource will support the future work of the Ambassadors as well as academics, librarians and publishers worldwide. Based on the information provided on the For Publishers pages of the DOAJ website, and the Principles of Transparency and Best Practice in Scholarly Publishing-it is intended to achieve the following:

• Highlight the issue of questionable publishing practices.

• Provide a checklist of criteria to identify questionable publishers (based on guidelines for editors working with applications to DOAJ).

• Identify other tools that assist in making informed decisions about where to submit articles for publication (based in part on the ThinkCheckSubmit initiative), and share case studies and examples gathered by DOAJ in over thirteen years of operation.

The DOAJ Best Practice Guide is curated and regularly updated as part of the general operations at DOAJ.

Figure 3 shows the increase in the number of journals from the Ambassador regions of Table 2. The results were obtained from the DOAJ administration system. It shows that the number of accepted journals from the Global South had double the growth rate observed for journals from the rest of the world. Like Figure 1, this illustrates the effectiveness of the Ambassador programme. Conclusions and Future developments

The participation of local Ambassadors and voluntary editorial team members was critical to the programme's efforts to combat cognitive injustice. Knowledge of the local context and contacts with the regional academic community, government and publishers were essential prerequisites. The Ambassadors developed an accurate understanding of how open access journal publication was perceived in their countries. With this knowledge they were able to disseminate information about open access that was sensitive to regional culture and local requirements. Most critically, communication was done in local languages. This, we suggest, facilitated the project's rapid progress. The DOAJ is convinced that it could not have achieved as much in such a relatively short time without the help of the developing world team. A lack of knowledge about open access licensing and copyright in the South and the absence of information in the literature and on the web about open access in languages other than English were impediments. Despite this, the project accomplished the following:

• The infrastructure to support open access publishing in the Global South has been enhanced.

•

The visibility of open access journals from the developing world has been improved.

• The risk of developing world researchers publishing with questionable publishers has decreased.

• Knowledge about good open access publishing practices has been enhanced among developing world publishers and a group of developing world academics by providing translations to information on Open Access publishing.

• Awareness about the DOAJ in the South has been enhanced.

• Statistics illustrating the objectives met are presented as part of this paper.

(Figure 1 & Figure 3).

• The DOAJ Best Practice Guide was realized.

21 The DOAJ's efforts to support cognitive justice for Southern researchers continue. We are discussing collaboration with a similar ambassador programme that Crossref wants to build. We are also talking with Creative Commons representatives on possibilities to have our DOAJ Ambassadors promote Creative Commons in their regions.

BIBLIOGRAPHY

  DOAJ Ambassador Programme: An Example Project for Promoting Cognitive Jus... ELPUB 2018 Results 13 During the first part of the programme (June 2016-July 2017) more than 3,000 open access journals from developing countries were reviewed with the help of local Ambassadors. Partner programmes led by Ambassadors have carried out OA publishing training for local publishers. The impact of the training on DOAJ usage is shown in Figure 1. Overall usage of the DOAJ from the Global South has increased with 21% from 2015 to 2016 and with 41% from 2016 to 2017. It must be acknowledged that increased awareness of open access worldwide could have contributed to this change.

Figure 1 .

 1 Figure 1. Increased usage of DOAJ by users in the Global South after starting the ambassador programme. The size of the dots is proportional to the amount of increase

  The DOAJ Ambassador Programme: An Example Project for Promoting Cognitive Jus... ELPUB 2018

Figure 3 .

 3 Figure 3. Increase in number of accepted journals in the DOAJ from the Global South compared with the rest of the world between Nov 2015 and Jan 2017

Table 1 .

 1 The initial breakdown of regions and languages, based on the IDRC list, before interviewing candidates and making appointments

	Region	Language
	Latin America	Spanish and/or Portuguese
	Middle East & Persian Gulf Arabic
	Africa (North/West)	Arabic and French
	Africa (South/East)	English
	India/Pakistan	Hindi
	Indonesia	Indonesian
	China	Chinese (Mandarin or Cantonese)

Table 2 .

 2 The breakdown of regions and language, and the number of Ambassadors for each region

	Region	Number of Ambassadors
	Latin America (Spanish/Portuguese)	1
	NW Africa & Middle East (Arabic & French) 3
	Africa (South and East) (English)	2
	India (English)	3
	China (Chinese)	3
	*Russia	3
	**Indonesia	4
	**South-East Asia	4

* Upon hearing about the Ambassador program from a presentation made by Tom Olijhoek in May 2016, DOAJ was approached by the President of the Russian Association of Science Editors and

  The group consists of 12 women and 11 men. Their biographies are available on the DOAJ website (https:// doaj.org/about#ambassadors).An initial training session took place on the Greek island of Crete in June 2016. The Ambassadors were taught how to process applications and reapplications with documentation and tools provided by DOAJ staff. The training included sessions on communication skills, cultural differences, questionable publishing, open access publishing and copyright and licensing. The training on cultural differences proved to be particularly useful. It guided the communication between DOAJ staff, who are based in different countries in Western Europe and the Ambassadors with their various cultural backgrounds. Working with diverse groups requires different approaches and methodologies for education and group management[START_REF] Meyer | The culture map: decoding how people think, lead and get things done across cultures[END_REF].After the training, the Ambassadors had access to recordings of the training sessions. Subsequent communications took place via Skype, Google Hangouts, WebEx etc. and training on expert topics like open access licensing was continued online.

	Training
	8

9

AUTHORS