Ramon Marti Solano

PROVERBS IN THE PRESS: FROM 'SENTENCE-LIKE UNITS' TO 'WORD-LIKE UNITS'

Keywords: Elliptical proverbs, lexical status, collocation, collocational framework, colligation, journalistic discourse

The main objective of this study is to examine how the British quality press makes use of a specific subgroup of proverbs and the reasons behind this stylistic choice. Nominal sentence proverbs such as Once bitten, twice shy or Out of sight, out of mind tend to appear in media discourse functioning as lexical items or 'word-like units' rather than 'sentence-like units', that is as "traditional maxims with deontic functions" (Moon, 1998: 22). These elliptical proverbs are likelier to be used as lexical items, integrated in sentences, bearing a specific syntactic function, than other longer and more structurally elaborated proverbs. Regular syntactic and lexical patterns seem to frame the instantiations of this type of proverbs in journalistic discourse. Their use provides a more popular and stylistically informal language register to this type of press.

Word-like units versus sentence-like units

Word-like units are made up of polylexematic items including mainly phrases and idioms such as at bay, second to none or in the blink of an eye, to mention just a few, that behave in discourse as monolexematic units and that have a regular syntactic function in the sentence.

Unlike word-like units, sentence-like units do not behave as single lexical items in the sentence, but rather they are self-contained utterances functioning autonomously in discourse.

They comprise sayings and proverbs but also conversational formulae, slogans, catchphrases and the like.

"Most of the early schemes and subsequent refinements (as in Gläser 1986a) are agreed in recognizing a primary division between 'word-like' units, which function syntactically at or below the level of the simple sentence, and 'sentence-like' units, which function pragmatically as sayings, catchphrases, and conversational formulae. Examples of the former are in the nick of time, a broken need and break one's journey, and of the latter There's no fool like an old fool, The buck stops here, and You don't say!" (Cowie, 1998: 4) This primary and fundamental dichotomy that splits up the whole heterogeneous mass of multi-word items of any natural language into two distinct groups or categories has been drawn as well in French phraseological and paremiological research by scholars such as Mortureux for whom "Le proverbe demeure un fait de discours, collectif, certes, mais non une unité lexicale." (Mortureux, 2003: 22) or Rey (1997: 345):

"Entre lexique et énoncé, la phraséologie, dans son centre (la locution, si l'on veut) est lexicale.

Mais le proverbe, l'allusion, la citation n'ont plus les mêmes caractères sémiotiques : ce sont des énoncés plus ou moins fixes et réemployables." (Rey, 1997: 345) Claims stating that proverbs cannot function as lexical items or that they are restricted to their quotational status seem to pervade paremiological research. This theoretical position does not obviously take into consideration the so-called elliptical proverbs, otherwise known as formulaic proverbs, nominal sentence proverbs or paired parallel phrases as they have been "described and mentioned (by Fillmore et al. 1988: 507 footnote), for example cold hands, warm hearts and garbage in, garbage out." (Moon, 1998: 152). These proverbs are widely instantiated in discourse as lexical units, sometimes superseding entirely their status as proverbs proper as illustrated by the following examples:

(1) The music industry is notorious for signing artists to enormous deals that embarrassingly fail to recoup their multi-million pound advances. But once bitten, twice shy does not apply to recording giant EMI.

(2) Dot.commery has been characterised by youthfulness, exuberance and dynamism -not, it has to be said, untinged by greed. But if the sector finds itself completely cold shouldered by oncebitten, twice-shy investors, that could change.

Proverbs and journalism

Observation of the language used in media discourse in general and in the British quality press in particular-increasingly inclined to update, modernise and vary their language register-has led us to undertake a study of the actual use of proverbs in this particular type of media discourse.

As many proverbs tend to be used in conversational exchanges, usually as a remark, a conclusion, a summary or a commentary of a given situation expressed by the interlocutor, they tend not to be frequently used in this type of discourse. However, journalists make regular use of traditional proverbs, more often than not manipulated or exploited, mainly to create catchy headlines (Mieder, 2004: 250) and to enhance the stylistics of their daily written production: a quick search in one of the archives of the main British or American newspapers yields significant and remarkable results in this respect. But the exploitation or manipulation of proverbs has been widely investigated either from a stylistic, cultural or even sociolinguistic point of view. Our main concern is the actual use of elliptical proverbs in their canonical forms when they are not used with their quotational status or even introduced or followed by a formula such as as the old saying goes or as they say, in other words what has been described as reduction à niveau inférieur (Arnaud & Moon, 1993: 336), that is to say when proverbs are downgraded to an inferior status from the sentence level.

Proverbs and their lexicalised variant forms

Proverbs are by and large less likely to present variant forms than other types of phraseological units, specially idiomatic verbal phrases such as lose the plot or turn back the clock which can be varied by means of substitution, lexical insertion or even stylistic exploitation. However, some examples of lexical substitution are attested as with Light come, light go, a variation on Easy come, easy go (Gläser, 1986: 112). But the main types of lexicalised variant forms are the result of a structural transformation of the original proverbial sentences mainly achieved through truncation as with a stitch in time/A stitch in time saves nine or a silver lining/Every cloud has a silver lining. Let us underline the importance of truncated forms of proverbs in contemporary English: lexicographical treatment in dictionaries of idioms is revealing of the fact that the truncated forms appear as the headphrase and that the proverbs themselves are listed as the variant forms or are simply mentioned in a footnote. This phraseological reactivation, otherwise considered as "downgrading", constitutes one of the main ways in which proverbs can have their place, as autonomous syntactic multi-word units, in different types of discourse, particularly in journalistic discourse: "downgrading from their canonical or earliest forms to lower-level grammatical units: a compound sentence to a single clause, or a clause to a group. The reduced forms can be seen in terms of ellipsis, since in many cases an allusion to the original and fuller form remains. However, they are institutionalized, and many can be regarded as lexical items in their own right." (Moon, 1998: 131) Many proverbs have thus become institutionalised idioms. Such is the case of the proverbs It's an ill bird that fouls its own nest which is normally used as the predicate verbal idiom foul one's own nest and Make hay while the sun shines, mainly instantiated as make hay. It is generally acknowledged that proverbs showing a higher degree of frequency in corpora tend to appear in their truncated form or otherwise downgraded to a simpler syntactic unit.

Another way in which proverbs are sometimes used, neither in their canonical form nor with their quotational status, has to do with their potentiality of being the target of stylistic exploitation or manipulation as illustrated by the examples that follow in which the proverbs You can't make a silk purse out of a sow's ear and The early bird catches the worm are singularly instantiated:

(3) Don Revie's Leeds United were gifted but ruthless to the point of cynicism, while Brian Clough turned silk-purse manufacture into a fine art form and produced Nottingham Forest's double European Cup-winning team from his particular collection of sows' ears.

(4) New, new new! It's come to be Charles Saatchi's big thing. New art, new names, new movements to spin, new careers to boost and inflect. Getting ahead of the others, snatching the early bird's worm, stealing a march on the rest.

Elliptical proverbs

Elliptical proverbs (Mieder, 2004: 44) such as Out of sight, out of mind or Once bitten, twice shy are nominal sentence proverbs that fall under one of the "finite number of proverb compositional or architectural formulas" (Dundes, 1981: 46) and that can have particular syntactic roles inside the sentence. It is precisely the fact that these proverbs have no main verb which makes them appropriate for playing the role of single lexical items, but from a semantic and a pragmatic point of view it is the holistic meaning of the string that may or may not be adapted to the contextual needs of the communicative situation. All proverbs considered for this piece of research have the same repeated syntactic structure.

Elliptical proverbs with no occurrences

Many proverbs that fall within this syntactic schema are not represented in the press. It should be noted that the fact of bearing the same syntactic structure is not therefore a guarantee for their use in discourse. The reasons are varied and they can be examined if we consider the following examples of proverbs 1 , traditional but unfamiliar, which have not been found in our searches in the newspaper archives:

Syntactic patterns of elliptical proverbs in the press

These elliptical proverbs can be sentence elements-usually subject, object or complementrealised as noun phrases or adjective phrases (rarely as adverbials). As adjective phrases they can be used both attributively and predicatively (in this latter case as subject complements).

As noun phrases they can function as the subject, the object, the complement of sentences or even as the complement in prepositional phrases.

Lexical and grammatical patterns

A certain number of regular lexical and grammatical patterns seem to recur in journalistic discourse. These proverbs are commonly used either as noun phrases or as adjective phrases and they reveal a number of collocations (proverb + approach), collocational frameworks (a + N + of + proverb) and colligations ((proverb) + copula + (proverb)) which seem to restrict their lexical and syntactic instantiations to a limited number of patterns.

Classification by frequency of use

The use of newspaper archives as linguistic corpora can be quite useful if we take into account that certain phenomena are thinly represented in well-known general corpora, for instance the British National Corpus. This corpus of 100,000,000 tokens encompassing different types of registers and representative of British English in the second half of the twentieth century can be of invaluable use to scholars for an enormous range of linguistic research. Nevertheless, if we launch a search for proverbs, we will find that they are practically inexistent. First come, first served, the most widely used proverb in the English language, has only 10 tokens, and the very popular and current No pain, no gain is found only once. With these figures, it is materially impossible to conduct a study into the use of proverbs as word-like units and their syntactic and lexical constraints. The study carried out by on the frequency of use of English and French proverbs shows that First come, first served is the most frequently used elliptical proverb in the Oxford Hector Pilot Corpus of 18 million occurrences out of a corpus of 240 proverbs (Arnaud &Moon, 1993: 325-326). Second in their frequency list comes Out of sight, out of mind (Arnaud &Moon, 1993: 327). Fist come, first served, classified as a non-metaphorical proverb by Moon (Moon, 1998: 22), is top of our list, which does not come as a surprise if we consider the following quotation:

The old phrases have become linguistic relics of sorts, and while many have indeed gone out of use, there are those that hang on and that people of the modern age would not want to miss. This certainly is the case with that ever present elliptic proverb "First come, first served", which belongs to one of the most popular proverbs today. (Mieder, 2004: 44) It has to be pointed out that the use of two different newspaper archives responds to the need of contrasting frequency results. All of the proverbs fall within the same frequency groups in both newspapers except for The more, the merrier which has a high frequency of use in The Guardian and a medium frequency of use in The Telegraph. Particular notice should be paid to the fact that First come, first served comes first with a strikingly similar number of occurrences in both newspapers.

High-frequency elliptical proverbs

We have carried out a thorough search in the archives of both The Guardian and The Telegraph to constitute three groups of elliptical proverbs according to the number of results found. Table 1 shows the elliptical proverbs with the highest frequency: The case of First come, first served is interesting in that no instances of actual proverbial usage have been found in our research. It is by far the most widely used proverb in English and it is primarily instantiated as illustrated in the following example:

(5) Ticket applications submitted during this period will be processed, subject to availability, on a first come, first served basis.

The phrase on a first come first served basis can be then analysed as a transformation of a proverb into a modifier (Moon, 1998: 43). This string may or may not appear hyphenated but it is, at any rate, highly institutionalised and lexicalised. Examples ( 6) and ( 7) show respectively the use of the phrase as a predicative and as an attributive adjective. The high frequency of use of this proverb is due to the fact that it is very often instantiated as a syntactic unit of a lower level (Arnaud & Moon, 1993: 329) 2 . As an attributive adjective the phrase collocates with nouns belonging to the same semantic group such as tickets, admission policy, system or access.

(6) Booking is essential, although breakfast (8.30-9.30am) is first-come-first-served and very popular with surfers, who swagger in… (7) Consumers have been warned that their broadband bills could soar after the EU opened the door to "net neutrality"unrestricted, first-come-first-served access to the internet.

The second most widely used proverb is Out of sight, out of mind. This phrase, whenever it functions as an adjective, tends to be used predicatively as a subject complement. When used attributively the phrase tends to collocate with the noun attitude. It is also frequent for this proverb to occupy the N2 position in the collocational framework a + N1 + of + N2, one of the commonest ways for the English language to instantiate proverbs in discourse, as shown in example ( 10):

(8) Our feet, he argues, are usually out of sight, out of mind, which is a shame as … (9) Groundwater suffers from an "out of sight, out of mind" attitude, but a report from … (10) When I moved from Edinburgh to Ibiza two years ago I really thought it would be a case of "out of sight, out of mind".

A higher degree of lexicalisation is achieved in such instances where the phrase is used as an attributive adjective with a noun other than attitude:

(11) The 'McWorld' culture is very much in the frame. Global corporations which exercise more power and possess more wealth than many decent-sized countries have created an out-of-sight, out-of-mind buying culture.

The more the merrier is usually instantiated as N2 in the collocational framework a + N1 + of + N2 in which N1 is generally realised by the nouns case or matter. Otherwise the string is used attributively and collocates with the noun approach.

(12) It's a case of the more the merrier when gathering like-minded souls in your teens and twenties, because you … (13) Charles Kennedy today urged a "the more, the merrier" approach at this week's anti-Bush demonstrations …

There are 24 results of No gain without pain in the archives of The Guardian. Most of them are instantiated as the full proverb "There is no gain without pain". On the other hand, it is the elliptical syntactic structure No pain, no gain the one that is usually instantiated as a word-like unit as illustrated by the examples below, which shows the adaptability of this particular structure for syntactic functions below the level of the sentence:

(14) For some reason, I seem to apply the no pain, no gain rule to exfoliators -unless I can feel the … (15) The massage was of the soft and gentle variety, which is exactly the kind of treatment usually guaranteed to wind me up (I'm more of a no pain, no gain girl), but it was blissful rather than irritating.

8.2. Medium-frequency elliptical proverbs The elliptical proverb Once bitten, twice shy 3 shows at the same time both "internal parallelism and contrast" (Moon, 1998: 299). Interestingly enough the proverb does not function only as a coda, as shown in example ( 16), since it may function as the subject of a sentence as in ( 17) or as a subject complement as in ( 18):

(16) "Maybe I'm wrong because I've not met the person yet, I really don't think I'd want to be with someone in the industry. I really don't think so. Once bitten, twice shy."

(17) But once bitten, twice shy does not apply to recording giant EMI.

(18) Although new -and the government says, more generous -provisions have been introduced since then, the industry is once bitten, twice shy.

Easy come, easy go is a remarkable example of a proverbial saying that has an exact synonym in a well-known and lexically related adjective. In fact the phrase can perfectly replace the adjective easy-going in all instances where the hyphenated lexeme is used. This is clearly shown by the noun with which both the phrase and the adjective collocate, attitude.

(19) But, still, Alexander Lebedev seems remarkably easy come, easy go about his fortune.

(20) Whether in a relationship or not, they may have a more "easy come, easy go" attitude to commitment.

We have found no occurrences of the variant Light come, light go, something which contrasts with the pervasiveness of Easy come, easy go in the newspaper archives. This clearly shows both the insignificance of the former and the prevalence and popularity of the latter. Garbage in, garbage out is a rather recent creation coming from the US as the use of the noun garbage (American word for rubbish) demonstrates. The meaning of this proverb is extremely close to the meaning of the traditional proverb You can't make a silk purse out of a sow's ear and appears to be replacing it in modern usage if we take into consideration the results obtained for both proverbs in the archives of The Guardian:

Low-frequency elliptical proverbs

Garbage in, garbage out 16

You can't make a silk purse out of sow's ear 6

It should be noted that the proverb in question follows the well-established and long-standing pattern N + in, N + out as exemplified by Ale in, wit out. It is fairly obvious that the syntactic structure facilitates the use of the proverb as a word-like unit as illustrated in the following example:

(21) John McFall, chair of the Treasury select committee, said too often investors, including pension funds, were the victims of a "garbage in, garbage out" culture that …

Conclusions

Paired parallel or elliptical proverbs such as First come, first served or Out of sight, out of mind are to be found quite frequently in journalistic discourse functioning inside the sentence as lexical items. Their not having an explicit verb form and the fact that their holistic meaning can be usually analyzable as a single-word unit expressing a certain type of attitude or human characteristic make them appropriate for being used in lower syntactic roles. There is a clear and growing tendency for these proverbs to be used in this type of discourse for stylistic purposes and as a means of introducing a more informal and popular register in the quality press.

Notes 1.

Our selection of proverbs has been made from the Oxford English Dictionary of Proverbs (see references).

2.

Their results show that 12 out of 15 occurrences of First come, first served are instantiated as on a first come first served basis.

3.

The variant Once smitten, twice shy has just yielded one result, a variation by the substitution of one of the constituents for a synonymous term belonging to a more literary register found in a headline.

  Ale in, wit out Cold hands, warm heart Full of courtesy, full of craft Grasp all, lose all Happy wife, happy life Long absent, soon forgotten Out of debt, out of danger Past shame, past grace Safe bind, safe find Soon learnt, soon forgotten Soon ripe, soon rotten Sooner named, sooner come

Table 1 .

 1 Article results in The Guardian and The Telegraph for high frequency elliptical proverbs

	HF Elliptical Proverbs	Guardian	Telegraph
	First come, first served	321	315
	Out of sight, out of mind	109	60
	The more, the merrier	91	32
	No pain, no gain	73	63

Table 2 .

 2 Article results in The Guardian and The Telegraph for medium frequency elliptical proverbs

	MF Elliptical Proverbs	Guardian	Telegraph
	Once bitten, twice shy	59	35
	Easy come, easy go	58	39
	Nothing ventured, nothing gained	33	43

Table 3 .

 3 Article results in The Guardian and The Telegraph for low frequency elliptical proverbs

	Low frequency	Results GUA	Telegraph
	Garbage in, garbage out	14	8
	More haste, less speed	13	5
	Least said, soonest mended	7	11


Cloud Computing and virtualization are largely adopted in the IT world and starts to gain momentum in networking to implement network functions such as switches or routers but also complex network service chains such as end to end security services. Surprisingly, while robustness is the first question that comes when deploying dedicated network infrastructures, cloud infrastructures provide little or no robustness guarantees for virtualized network functions.

As a matter of facts, traditional Cloud infrastructure are several order of magnitude slower than dedicated network infrastructures to react to faults. In this work, we aim at providing robustness guarantees for network functions deployed with OpenStack, the leading open source project for cloud computing.

Multiple options are possible to implement such robustness in OpenStack but we designed an approach that minimizes the changes required in OpenStack in order such that it can be smoothly integrated with the official releases. Our well documented implementation follows the best programming practices to guarantee its correctness and integration in a large open source project. Our tests in a real Open-Stack environment composed of multiple compute nodes validate our choices and prove its usability.

1 Introduction

Context

Cloud computing is a set of technologies and infrastructures that allow convenient and on-demand access to shared computing resources (servers, networks, storage, applications, and services) without the end user knows the physical location, the infrastructure, and configuration of the system providing the service [START_REF] Mell | The NIST Definition of Cloud Computing[END_REF].

Typically, the service offered to the public is pay-for-use. The Cloud Provider has software resources, depending on the service it wants to deliver, and hardware resources (servers and clusters) located in various data centers spread across different parts in the world, connected to each other through private high-speed networks.

Three common cloud delivery models have become widely established and formalized; each model should satisfy the requirements of a particular class of users:

1. Software as a Service (SaaS): the provider enables the users to use applications that are executed on its servers; The user can access the application using a client like a PC, smartphone, tablet, etc.

In this case, the user does not have to worry about the configuration or the installation of the application; the Cloud provider has to maintain and update the applications executed on the servers, the operating system, and the computational resources.

2. Platform as a Service (Paas): the provider offers a platform where the users can develop and deploy their applications. The users do not have to worries about system configuration at the lower level like Operating system, storage or hosting system;

3. Infrastructure as a Service (IaaS): the provider offers a virtual infrastructure (CPU, memory, storage, and network) that the users can use in place of or with the physical infrastructure. The users have to configure the operating system, the environment, and the network.

During this project, we work with OpenStack, an open source project for cloud computing, typically for IaaS clouds.

[2]

Motivations

In the present days, companies start to move Network functions to the Cloud; Networks are built in reality to be robust at failures (if one network device between 2 hosts filed, the hosts must be reachable each other ).

Up to now, cloud infrastructures provide elasticity, but not robustness.

Goal

The goal of this project is not to design and propose new algorithms to guarantee the robustness of a chain(it is not a research project). The goal is to build a stable OpenStack environment where it is possible to implement robustness solution that have been proposed in the literature without too much effort.

Challenges

OpenStack is a big and complex project, up to now it has around 4 million Line Of Code, more than six thousand contributors, and more than 400 thousand commits.

[3] One of the challenges is that a new version of OpenStack is released every six months with significant changes from the previous version. We want that in case the Community decides to modify OpenStack, the algorithm should be reimplemented with the minimum effort.

The documentation for the developer is limited(it is hard to find a true class or sequence diagram), and usually, it is not updated.

Contributions

Produce a documentation for new developers to contribute in OpenStack (especially in the Nova Project). Propose different solutions in order to add Robustness in the OpenStack infrastructure, without compromise the main functionalities; finally, implement one solution and publish all the code and the documentation on a public repository [START_REF] Di | [END_REF] that allow other developers to contribute.

State Of The Art

OpenStack

OpenStack is an open source project for cloud computing; it is composed of seven different main modules. Each module provides APIs so administrators can manage resources through dashboards, while users can access them through a web interface, a command-line client, or a software development kit that supports APIs. [4] OpenStack is mainly written in Python with a modular architecture, it is released under the terms of the free Apache License and is currently maintained and supported by the OpenStack Foundation, a non-profit entity founded in September 2012.

The OpenStack community collaborates around a six-month, time-based release cycle with frequent development milestones. During the planning phase of each release, the community gathers for an OpenStack Design Summit to facilitate developer working sessions and to assemble plans.

Hundreds of the world's largest companies rely on OpenStack to run their businesses every day, reducing costs and helping them move faster. OpenStack has a strong ecosystem, and users seeking commercial support can choose from different OpenStack-powered products and services in the Marketplace. Probably Nova is the most famous among the OpenStack projects, the most complicated and the most distributed. It provides virtual servers on request. A large number of processes work together to transform end-user API requests into running virtual machines. [START_REF] Paternò | OpenStack -Nova e Glance[END_REF] Figure 2: Nova Architecture Nova is composed of seven different modules:

1. Nova-API: a REST-ful API that accepts incoming commands and interacts with the OpenStack Cloud;

2. Nova-compute: a daemon that creates and destroys virtual machine instances via the HYPERVISOR API;

3. Nova-scheduler: takes a request from the queue and chooses where the virtual instance should be executed;

4. Nova-conductor: provides nova-compute services(for example create/delete instances) interacting with the Database;

5. Nova-DB: collects most of the build-time and run-time information;

6. Nova-console: it provides console services to allow the end user or the administrator to access the console of its virtual instances through a proxy.

7. The queue works as a central hub for exchanging messages between daemons. Normally this is implemented with RabbitMQ;

It is important to know that we can receive user commands from Horizon (Web Interface) and Nova-Client(an independent project, that provides to the users a Command Line Interface to interact with Nova-API).

Neutron

OpenStack Networking is a pluggable, scalable, and API driven system to manage networks and IP addresses in an OpenStack-based cloud. Like other core OpenStack components, OpenStack Networking can be used by administrators and users to increase the value and maximize the utilization of existing data center resources. [START_REF] Consalvi | Studio e implementazione del paradigma SDN attraverso Openstack e Opencontrail[END_REF] Neutron, the code name of OpenStack Networking, is a standalone service that can be installed independently of other OpenStack services. Neutron includes many technologies one would find in a data center, including switching, routing, load balancing, firewalling, and virtual private networks. These features can be configured to leverage open-source or commercial software; [START_REF] Tomassilli | Virtual networking in OpenStack[END_REF] Neutron also provides a framework for third-party vendors to build on and enhance the capabilities of the cloud. 1. Neutron-Server: this service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port.

2. Neutron-Agent: runs on each compute node to manage local virtual switch (vswitch) configuration. The plug-in that one use determines which agents run. This service requires message queue access and depends on the plugin used.

Keystone

Keystone is the Identity Service module; it manages the users and all the privileges that they have on the entire infrastructure and the services that are implemented in OpenStack [START_REF] Topol | Identity, Authentication, and Access Management in OpenStack[END_REF]. Keystone provides a central directory where users are mapped to the services they can access. It supports several authentication methods: user and password authentication pair, token-based authentication systems, certificate-based authentication (like that of Amazon EC2, based on X.509 certificates).

The key concepts in Keystone are:

• User: Digital representation of a person, system or service using Open-Stack; Each user has credentials (user name and password, username and API key, or a Keystone token).

• Token: An alphanumeric string that is used in order to access a particular resource; each token has a scope that describes what resources are accessible with it. It has a limited duration and can be revoked at any time.(it is very similar to the Kerberos protocol)

• Tenant: A user group that has shared resources.

• Endpoint: An accessible network address, usually described by a URL, in order to use a service.

• Service: an OpenStack service (Nova, Swift, Neutron, etc.) that provides one or more endpoints which users can access resources and perform operations.

• Role: rights and privileges that a user gains, allowing them to perform a specific set of operations and requesting certain resources. One user can assume different roles in different tenants and assume multiple roles within the same tenant.

If a user wants to start an OpenStack service (for example, creating a virtual server) first, they will have to authenticate using a keystone user name and password. If the credentials are correct, Keystone will send the user a token that will allow them to use the services it has access to. A token is always temporary, if it expires and the user requires another service, he must first renew it.

Glance

Glance provides discovery, registration, and delivery services for disk and server images. Stored images can be used as a template. It can also be used to store and catalog an unlimited number of backups [2]. Glance API provides a standard REST interface for querying information about disk images and lets clients stream the images to new servers.

Swift

Swift is a scalable, redundant storage system. Objects and files are written to multiple disk drives spread throughout servers in the data center, with the OpenStack software responsible for ensuring data replication and integrity across the cluster. Storage clusters scale horizontally simply by adding new servers. Should a server or hard drive fail, OpenStack replicates its content from other active nodes to new locations in the cluster [2]. Because OpenStack uses software logic to ensure data replication and distribution across different devices, inexpensive commodity hard drives and servers can be used.

Cinder

Cinder provides persistent block-level storage devices for use with OpenStack compute instances. The block storage system manages the creation, attaching and detaching of the block devices to servers. Block storage volumes are fully integrated into OpenStack Compute and the Dashboard allowing for cloud users to manage their own storage needs. Block storage is appropriate for performance sensitive scenarios such as database storage, expandable file systems, or providing a server with access to raw block level storage [2]. Snapshot management provides powerful functionality for backing up data stored on block storage volumes. Snapshots can be restored or used to create a new block storage volume.

Horizon

Horizon provides a web interface developed using Django, an open-source framework written in Python, to interact with OpenStack services depending on the privileges you have, there are two types of interfaces:

• User interface: allows for each project to which the user is assigned: to launch virtual machine instances, create virtual networks, and apply firewall rules, to have information about the resources available for each project, to create images and snapshots of virtual machines and simply switch from one project to another.

• Administrator Interface: In addition to user interface operations, we can set up and manage all projects, create and manage users (for example, assign a user to a project). We can get all system information (such as services Active in the Cloud and quotas allocated to each project), create new flavors and manage system resources. Heat is not a primary OpenStack project like the ones described before, but it can be easily integrated with the OpenStack environment.

The key concepts in Heat are:

• Resources: Objects that will be created or modified during the orchestration. Resources can be networks, routers, subnets, instances, volumes, floating IPs, security groups and more.

• Stack: In Heat, a stack is a collection of resources, for example a Network function chain.

• Parameters: Allow the user to provide input to the template during deployment. For example, if you want to input the name for an instance in an orchestration, that name could be input as a parameter in the template and change during each run time.

• Templates: How a Stack is defined and described with code. There are four main components of the Heat project:

1. Heat-Client: is the CLI that communicates with the Heat-API(Heat is also integrated with Horizon, so it is possible to communicate with Heat-API, through the Web interface ).

Heat-API:

The component that provides an OpenStack-native REST API that processes the requests and sends them to the heat-engine.

3. Heat-Engine: is the brains of the operation and does the main work of orchestrating the launch of templates and providing events back to the API consumer.

4. Heat-DB: Store all the information about the Stacks created.

NFV & SNFC

Network Functions Virtualization(NFV) is a concept that uses the technologies of IT virtualization to virtualize entire classes of network node functions into building blocks that may connect, or chain together, to create communication services [START_REF] Gray | Network Function Virtualization[END_REF].

NFV describes and defines how network services are designed, constructed and deployed using virtualized software components and how are decoupled from the hardware upon which they execute.

Network functions virtualization directly addresses most of the limitations associated with using the traditional network and brings many additional benefits. It offers a framework to completely transform the way networks are architected, deployed, managed, and operated while offering many layers of improvement and efficiency across all of these [START_REF] Chayapathi | Network Functions Virtualization (NFV) with a Touch of SDN[END_REF].

Why use NFV:

• Hardware Flexibility: NFV uses regular hardware, network operators have the freedom to choose and build the hardware in the most efficient way to suit their needs and requirements.

• Scalability and Elasticity: For scaling up the traditional network equipment's capacity takes time, planning, and money. This problem is solved by NFV, which allows capability changes by offering a means to expand and shrink the resources used in the Cloud. If any of the Virtual Network Function(VNF) requires additional CPU, storage, or bandwidth, it can be requested and allocated to the VNF from the hardware pool. In a traditional network device, it would require either a full device replacement or a hardware upgrade to alter any of these parameters.

• Rapid Development: NFV provides the means to easily deploy a different vendor's solution without the heavy costs associated with replacing an existing vendor's deployment, it keeps network operators from being locked into a particular vendor. Service Network Function Chain (or Service Function Chaining) provides the ability to define an ordered list of network services (e.g., firewalls, load balancers). These services are then grouped together in the network to create a service chain. The "chain" in service chaining represents the services that can be connected across the network using software provisioning. Network service chaining capabilities mean that a large number of virtual network functions can be connected together in an NFV environment. Because it's done in software using virtual circuits, these connections can be set up and torn down as needed with service chain provisioning through the NFV orchestration layer.

Robustness

In this section, we define the concept of Robustness related to Service Network Function Chain. Each Instance(Virtual Function) of the chain must run in a physical Host(Compute Node) inside the Cloud infrastructure; If the Host that runs the Instance fails(for example a hardware failure), the chain is not working anymore.

• Robustness: an Integer number bigger or equal than 0, assigned to an SNFC indicating the minimum number of simultaneous Compute failure inside the Cloud infrastructure such that the Chain is not compromised and it is serving the users without breaks.

For example, if we instantiate a chain with robustness 2 and two compute nodes in the Cloud infrastructure crash, for the robustness property, we are sure that the chain is working. If we have three crashes, we do not have the guaranty that the chain is still working.

There is a lot of work around SNFC and robustness, as we said before, the goal of this work is not to provide new algorithm or new definitions of Robustness; For this reason, we are not going to explain in detail how to guaranty Robustness in a system; we just present the main properties(Redundancy and placement) that a Cloud infrastructure needs in order to guaranty the robustness described in the paper "To Split, or not to Split: When SFC Robustness is at Stake" [START_REF] Moualla | To Split, or not to Split: When SFC Robustness is at Stake[END_REF].

The idea is to add redundancy; let's take in consideration a chain with a given robustness = 1 (so it has to be still available if one Compute breaks in the system ), we can think to create two chains to guarantee the robustness. Is it enough in order to guaranty the robustness? In this example, we can see that redundancy is not enough; if Compute 2 breaks in the first case, we can see that the first copy of the chain (f') and the second copy of the chain(f"), are not working anymore. In the second sample if Compute 2 breaks, the copy f' is not running anymore, while the copy f" is working, because the crash of Compute 2 does not have any effect for f".

So in order to guaranty Robustness, we need redundancy, and we need to place the functions of the chain correctly in the Compute Nodes.

3 Our Approach

Solution Proposed

OpenStack provides various API for developers; in this project, we focalized in the API provided by Horizon and Nova. When an instance is created, the message that Nova receives from the API contains multiple properties and different options(Network, vCPU, Memory, etc).

For our purposes, we focus on two properties in the function called when an instance is created[14]:

• AntiAffinityGroup Option: Anti-Affinity groups allow us to make sure instances are on different Hosts.

• Instance Hints: Hints allow us to send to Nova personalized information that are not provided normally(for example the robustness of a chain)

Solution 1

A first simple possible solution, it is just to modify Horizon, without affecting the core of OpenStack. When a User creates an instance(or a chain) with an optional parameter (Instance Hint "Robustness:Integer"), we intercept the call in Horizon, before that it is sent to Nova and we modify the call in this way:

• Create Robustness + 1 (or more)copy of the instance.

• Create a new Anti-Affinity group.

• Put the instances in the same Anti-Affinity group.

In this way, we are sure that the instances are in different Compute Host(Anti-Affinity Group), and we create all the copy that we need to ensure a robust instance. In the case of a Chain, this process is executed for any function of the Chain.

PRO:

• Simple to Implement.

• Correctness of the Anti-Affinity Group is proven, it is part of Nova release.

CONS:

• Impossible to implement directly complex robustness algorithms(we do not have total control of the Scheduler).

• We don't have control of the Anti-Affinity Group option; if the community decide to not support anymore this option, we have to reimplement the entire solution.

• Horizon is not the only way to create an instance(or a chain); we need to modify also Nova-Client(Command Line Client for Openstack)

Figure 9: Changes in Horizon to allow robustness

Solution 2

In this case we need to go in the core of OpenStack; in particular, we modify the Nova-API, and we create a new scheduler without modifying or delete the default scheduler(FilterScheduler). When Nova receives the message for the creation of an instance, first we check that in the properties of the instance there is the Hint "Robustness", if the property is not there, call proceed regularly(default scheduler and one instance created). If the Hint "Robustness" is specified and it is an integer >= 1, the control goes to our Personalized Scheduler(that chooses the number of copies to create and where to place them).

PRO:

• We have total control of the Personalized Scheduler.

• If the community decide to modify the Default scheduler our solution will continue to work

• In this solution we modify only Nova.

CONS:

• Nova is a big and complex project, it is difficult to modify.

• Change the API

• Dependency on the implementation of Nova (while previous option just depends on the API) PRO:

• We have total control of the Personalized Scheduler.

• No problem if the community decide to modify the Default Scheduler or Horizon CONS:

• Horizon is not the only way to create an instance(or a chain); we need to create a new API also for Nova-Client(Command Line Client for OpenStack).

• we have to create one API for Nova, Horizon and for Nova-Client.

Implementation of Sol. 2

Knowing that OpenStack is evolving very fast, and we need a solution that is durable and adaptable to the new version of OpenStack easily. We decide to modify Nova (the core of Nova is stable, it is difficult that the community decides to change its architecture, most of the commits in the Nova project are for debugging); without affecting the Horizon API(it is common that the community decides to modify the API, for example, to support new features).

Allocation Scheduler

First of all, we create a new scheduler. Each scheduler is a python file, saved in the directory nova/scheduler/SCHEDULER NAME.py.

A scheduler in OpenStack has a particular structure, defined in the file nova/scheduler/driver.py, each scheduler defined must inherit the class Scheduler in the driver.py file, in order to work correctly. To test our infrastructure, the scheduler that we implemented is simple, and it does not take much effort to modify it to implement a different scheduler.

If someone has to implement its own scheduler, it has just to modify the method schedule (Line: [START_REF] Di | Create a robust instance in OpenStack[END_REF]. The RRScheduler returns the list of hosts that can satisfy the request of the Instance(for example if the compute has enough vCPUs or vRAM); after the filtering process ( filter hosts method Line: 27), it sort the compute nodes by the IDs of the compute nodes and return the sorted list to the select destinations method (Line: 34).

Modification of Nova-API

When Nova receive a message of instance creation, the first method that is called is create (Line: 10) in the file: nova/api/openstack/compute/servers.py. We moved the code inside create in a new method create, and in case the robustness is not in the body of the instances the create method is used to build the instance with the default scheduler.

If the instance has the attribute "robustness", our Personalized creation (Line: 15) is called.

# ## servers . py @wsgi . response ( 202 ) @extensions . expected_errors (( 400 , 403 , 409 ) ) @validation . schema ( schema_server_create_v20 , '2 . 0 ' , '2 . 0 ') @validation . schema ( schema_server_create , '2 . 1 ' , '2 . 18 ') @validation . schema ( schema_server_create_v219 , '2 . 19 ' , '2 . 31 ') @validation . schema ( schema_server_create_v232 , '2 . 32 ' , '2 . 36 ') @validation . schema ( schema_server_create_v237 , '2 . 37 ') def create ( self , req , body ) : We focus just on the main part of the Personalized creation method (it has around 250 LOC); First of all we extract the value of the robustness from the body of the call (Line: 5);

#
Next step is to create the personalized scheduler(Line: 15), and get the list of the Compute IDs where to put the instances (Line: 16) In case the number of Hosts returned by the scheduler is not enough to satisfy the robustness, we rise an exception( Lines: [START_REF]Launch an instance, OpenStack Ocata Documentation[END_REF][START_REF] Hugenbruch | A guide to testing in OpenStack[END_REF].

If the Compute Nodes are enough, we create the instances in the Hosts returned by the scheduler (done inside the for cycle at Line: 21)

Keep track of the instances

Ones that we have multiple copies of the same instance, correctly distributed on the Compute nodes, we need to keep track of these instances. Each instance has a unique ID, and by default, we don't know if an instance is a copy of a robust instance or a normal one.

So we created a new Database call "Robustness"; when a Robust instance is created, we create a RobustID and we assign it to each copy of the instance created.

The following code is executed after the allocation of the instances in the Compute Nodes, in the Personalized creation method in the file nova/api/openstack/compute/servers.py.

After the allocation, the IDs of the instances created, are stored in the list instance created. We create an id for grouping all the copy of the same instance, and keep saving the robustness value robustness id (Line: 3).

We save the tuple (robustness, robustness ID) in the table robustness (Lines: 6-10), and the tuple (robustness id, instance id) in the table instances (Lines: 12-18). cur . execute ( """ INSERT INTO robustness ( robustness , robustness_ID ) VALUES ( % s , % s ) ; """ % ( " '" + str ( robustness ) + " '" , " '" + robustness_id + " '" ) ) In case the user wants to remove the instance created (and the copies), it has to manually select all the copy of the instance and run the delete command from Horizon or the Nova-Client. We want automate this process, so we modify also the delete method in the file: nova/api/openstack/compute/servers.py If we found the ID of the compute that the user wants to delete in the instances table, we select all the instance id with the same robustness id (Lines: 10-11), and delete all the instances(for cycle Line: 13) # ## servers . py delete method def delete ( self , req , id ) :

""" Destroys a server .

Test and Validation

First of all, we deployed OpenStack(Oca ta Version) in an infrastructure with one Controller node (in this case the Controller also manage the network), and multiple Compute nodes.

Figure 13: OpenStack Infrastructure

We tested the infrastructure to check the correctness of our installation [START_REF]Launch an instance, OpenStack Ocata Documentation[END_REF], and after that, we installed HEAT(orchestration engine) to define chains ( launch multiple composite instances based on templates in the form of text files). We can create a chain, but we cannot ensure the robustness yet. However, as we have seen in Section. 2.3, in order to guarantee the robustness, we need to replicate the functions of the chain and correctly choose in which Compute node build each network function.

We need to test our code before to insert the modification in our infrastructure; Fortunately, OpenStack provides a large number of unit tests( more than 16.000 ), each change in the code has to pass all the unit tests; If our code is compatible with all the unit tests, we modify the code inside our deployment.

To launch our code with the unit tests, we set up a virtual environment with the package "virtualenv"(a Python package that creates an environment, with all the packages needed that has its own installation directories, that doesn't share libraries with other virtualenv environments and optionally doesn't access the globally installed libraries either)[16] [START_REF] Hugenbruch | A guide to testing in OpenStack[END_REF].

Of course, we cannot launch all the unit test for each modification of the code, so to automate and standardize testing, we used Tox(a generic virtualenv management and test command line).

We can use Tox for:

• running tests in each of the environments, configuring your test tool of choice

• checking that package installs correctly with different Python versions and interpreters

• acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing. We can see(Figure : 19) that the instances created are scheduled in different hosts( the scheduler is working correctly). Correctly, we receive an error informing that the robustness is too big, and no instance is deployed.

Conclusion

OpenStack system provide an Infrastructure as a Service cloud with good scalability and manageability. In the current version (Ocata), the installation is manageable also for who is not used in system administration practice, the documentation for the final users is good and continuously updated by the OpenStack community.

For developers that want to start to contribute the situation is different. As we said, OpenStack is continuously evolving, and the documentation for the developers is not updated in parallel, with the OpenStack code and Architecture.

One solution to this problem can be to build an LTS(Long Term Version) version of OpenStack supported for a couple of years and in parallel developing new versions every six months (like the Ubuntu OS )

Regarding robust SNFC; we proposed different solutions, and we implemented the one that best fits for our goals; we can see that if a system is not designed with the robustness concept in mind since the beginning, it is difficult to add it later.

Future work

We created an environment that allows to multiply and schedule the instances of a SNFC, in the next step we need to create the connection between the instances created. Let's take following example; a user wants to create a chain of two functions robustness = 1. At this point, the instances are correctly placed. They need to communicate each other; in this example, the input traffic should be directed to the instances f1, the output of the instances f1 directed to the input of the instances f2, and finally, the output of the instances f2 directed to the Output of the chain.

One idea can be to use Load Balancers between the Instances representing different functions; Fortunately, OpenStack (Neutron project), provide the API to build Load Balancers [20]. So the idea is to create load balancers after the creation of the instances, like in the following example.

Figure 1 :

 1 Figure 1: OpenStack Modules [4]

Figure 3 :

 3 Figure 3: Neutron Architecture

Figure

  Figure 4: Dashboard

Figure 5 :

 5 Figure 5: Heat Architecture

Figure 6 :

 6 Figure 6: Network Function Virtualization

Figure 7 :

 7 Figure 7: Service Network Function Chain

Figure 8 :

 8 Figure 8: Allocation Chain Example

Figure 10 :

 10 Figure 10: Changes in Nova to allow robustness

Figure 11 :

 11 Figure 11: Integrate new API in Horizon and Nova

#

  ## servers . py def _ P e r s o n a l i z e d _ c r e a t i o n ( self , req , body ) : """ Creates new instances using my scheduler . """ robustness = int ( body [ " os : scheduler_hints " ] [ " robustness " ] ) class personalized_Obj () : def __init__ ( self , num_instances , ignore_hosts = [ ] ) : self . num_instances = num_instances self . ignore_hosts = ignore_hosts spec_obj = personalized_Obj ( body [ " server " ] [ " max_count " ] ) context = req . environ [ ' nova . context '] pers_schedule = RRScheduler () ll = pers_schedule . se l e ct _ d e st i n at i o ns ( context , spec_obj ) [ : robustness + 1 ] if len ( ll ) < robustness + 1 : raise exc . HTTPBadRequest ( explanation = " Not enough Host for robustness = " + str ( robustness ) ) ins tances _creat ed = [ ] for i in ll : context = req . environ [ ' nova . context '] server_dict = body [ ' server '] # ## CONTINUE WITH THE CREATION ###

#

  ## servers . py _ P e r s o n a l i z e d _ c r e a t i o n method robustness_id = str ( uuid . uuid4 () ) cur = db . cursor () try :

Figure 12 :

 12 Figure 12: Database robustness

  """ # CODE BEFORE ...# # db robustness connected cur = db . cursor () chain_id = data [ 0 ] [ 0 ] cur . execute ( """ SELECT * FROM instances WHERE chain_id = % s """ % ( " '" + robustness_id + " ' " ,) ) instances = cur . fetchall () for i in instances : try : self . _delete ( req . environ [ ' nova . context '] , req , i [ 1 ] ) except exception . InstanceNotFound : msg = _ ( " Instance could not be found " ) raise exc . HTTPNotFound ( explanation = msg ) except exception . I ns t a nc e U nk n o wn C e ll as e : raise exc . HTTPNotFound ( explanation = e . format_message () ) # ## CONTINUE ...###

Figure 14 :

 14 Figure 14: Subset of UnitTests for Nova-API

Figure 17 :

 17 Figure 17: Creation of a robust instance

Figure 18 :

 18 Figure 18: Check the creation of the robust instance with Horizon GUI

Figure 19 :

 19 Figure 19: Check the placement in the admin Web interface

Figure 20 :

 20 Figure 20: Delete one copy of the robust instance

Figure 21 :Figure 22 :

 2122 Figure 21: Check if all the copies are deleted

Figure 23 :

 23 Figure 23: Example of placement

Figure 24 :

 24 Figure 24: Load Balancers to split the traffic

Neutron-Plugin: the neutron-server requires indirect access to a persistent database. This is accomplished through plugins, which communicate with the database using AMQP

.4. Neutron-DB: keep track of the networks created

Demo

In this chapter we present a demo; In the infrastructure, we have one controller node and 3 compute nodes ("compute1","compute2","compute4"). The video of the demo is online at the link: OpenStack Demo. [START_REF] Di | Create a robust instance in OpenStack[END_REF] First, we test our infrastructure, with one normal instance.


Anthony Couzinet

Jérôme Ferrari

Laurent Gros

Christophe Vallet

Daniel Pierrat
email: daniel.pierrat@cetim.fr

Experimental Study and Numerical Modeling of Incompressible Flows in Safety Relief Valves

Keywords: Safety valves, Turbulence modelling, Cavitation, Flow visualization. NOMENCLATURE

The sizing of relief safety valves is crucial for pressure vessels and piping equipment and it can be sensitive to working conditions. Understanding the flow dynamic through the valve becomes the only way to predict their behavior under different operating conditions. This study consists of two complementary parts. A first experimental step focuses on the influence of the geometrical characteristics of the valve (ring position) and operating conditions (free or full cavitation). The second step describes the numerical modeling developed to simulate the single phase flow through the valve. The behavior of turbulence models available in the standard CFD software is explained, particularly the effect of the viscosity limiter near the stagnation point of the valve. Finally, a post-processing method is proposed to evaluate the possible location of cavitation appearance starting from results of single-phase simulations.

INTRODUCTION

Safety relief valve (SRV) is still the ultimate security component of pressure vessels or piping equipment. It does not take the place of a regulating or control valve but it aims to protect devices and human beings by preventing damage due to overpressure in the system. This is ensured by discharging an amount of fluid when an excessive rising of pressure occurs. Then sizing, design and choice of SRV are crucial to ensure the best operating conditions, which is the guarantee of maximum protection. An appropriate sizing of SRV depends on the flow conditions in the system. In single phase flows, the sizing equations are well established for both compressible and incompressible flows ASME (2001), API 520 (2001), NF EN 60534 (2012). The SRV discharge capacity tends to reduce under two-phase flow conditions what is responsible for serious damages or accidents. In particular cavitation flows may cause valve performance loss.

Prediction of these characteristics is not easy and several methodologies exist in the literature lying on different modeling approaches (see [START_REF] Pinho | Experimental study of two-phase flow induced by cavitation through a safety relief valve[END_REF], [START_REF] Kourakos | Experimental study and modeling of single-and two-phase flow in singular geometry and safety relief valves[END_REF] for a detailed presentation).

Understanding the flow behavior through the valve becomes a real challenge in order to improve sizing of the devices.

Experimental and numerical investigations of single and two-phase flows in SRV have been driven in order to explain flow characteristics following different lift valves. In fact, most papers on the subject concern experimental studies or theoretical modeling of single-phase compressible or incompressible flows. Moreover, the number of numerical studies has significantly increased those past ten years thanks to the local understanding of flow dynamics through the safety valves allowed by nowadays computational software. But CFD simulations are mainly performed to model singlephase flows either incompressible or [START_REF] Song | Three dimensional CFD analysis of a spring-loaded pressure relief valve from lift and re-closure[END_REF], [START_REF] Davis | Predicting Globe controle Valve Performance -Part 1: CFD Modelling[END_REF], or compressible [START_REF] Moncalvo | Sizing of safety valves using Ansys CFX-Flo[END_REF], [START_REF] Dossena | Numerical and experimental investigation on the performance of safety valves operating with different gases[END_REF]. A remarkable lack of references can be stated concerning two-phase flow analysis. However, cavitation problematic is still studied with great interest particularly to determine valve size influence in these critical conditions given geometrical similarities. The interest of this paper is to validate numerical modeling by using a large experimental database.

EXPERIMENTAL FACILITIES

Mock-up

If the working principle of SRV lies in the equilibrium between the pressure forces on the upstream face of the disc and the force applied by the spring, the experimental set-up is different: flow characteristics are measured for a given valve lift and the correlation between measurements of global characteristics for specific operating points (cavitation condition or not) and flow visualization is studied. So the corresponding mock-up of a safety relief valve H (see Fig. 1) is built to ease flow visualization and to have its fluid vein match precisely the original valve one.

The body, the ring and the disc lower part are in Plexiglas. The spindle is in titanium and has its diameter reduced from 14 to 7.5 mm over 1cm to allow the measurement of axial strain. The nozzle is in steel. Two different rings are made to simulate two common positions of the real ring. The upper position sees the ring top at the same altitude as the nozzle top whereas the lower position is 3.78 mm under and corresponds to the real ring lowest possible position.

The bonnet is replaced by a mechanical system including a step-by-step motor and a position gauge to allow an accurate guidance of the plug position.

Experimental devices / instrumentations

The model is rigged up in a loop dedicated to cavitation experiments. It is possible to set accurately the downstream pressure even to sub-atmospheric ones. The fluid media used is common demineralized water maintained at 23°C.

The setup is optimized to keep pressure gauges as far as possible from potential perturbations (see Fig. 2).

Fig. 2 Experimental setup

Test procedure

Two experimental series are performed: one without cavitation and one at full cavitation. For the series without cavitation, the downstream pressure is set to the maximum value of 4 bars.

The flow rate is then set to the maximum possible before the cavitation onset and it is then reduced stage by stage until reaching the minimum value. For the full cavitation series, the downstream pressure is set to the sub-atmospheric pressure of 0.4 bar. As there is no simple mean to know if full cavitation is reached, the flow rate is increased stage by stage until obtaining the maximum allowed by the pump. Only post experimental data processing shows that full cavitation conditions are met. For both series, variables are measured for the two ring positions and 18 opening heights ranging from 0.15 mm to the full lift: 9.5 mm. Flow conditions are stabilized at each stage for one minute to enable a suitable averaging for each stage during data processing.

Test procedure

During the experiment, each test is recorded using a conventional camera. Furthermore, a high-speed camera is used at 12,000 frames per second to observe various cavitation patterns (See a sample in Fig. 3).

Flow capacity

Considering a turbulent single phase flow in the framework of regulation or control valves, the pressure drop between the inlet and outlet of the relief valve is a linear function of the square of the flow rate NF EN 60534 (2012), thus:

0   down up v P P K Q   (1)
Where Q is the flow rate in m3/h, Pup and Pdown are respectively the upstream and downstream pressure in bar, /0 is the relative density to water at 15°C, Kv is the flow coefficient in m3/h which represents the flowrate under a pressure equal to one bar. The flow coefficient is a dimensional quantity that is largely used in industry applications. It is a measure of the valve capacity. This sizing equation is evaluated starting from the results of the series without cavitation to estimate Kv. We have decided to follow the regulation devices formalism in the case of a safety relief valve because the flow is studied for several positions of disc lifts as it occurs in regulation or control valves.

In case of full cavitation conditions, valves are known to have reduced flow capacity, the flow rate does not depend anymore on the downstream pressure, it becomes NF EN 60534 (2012):

vap f up l v P F P F K Q   (2)
Where Fl is the pressure recovery factor, Pvap the vapour saturation pressure and Ff the water critical pressure ratio factor defined as: (3)

Where Pc is the water critical pressure. Due to the low value of the vapor saturation pressure in the present experiment (0.028 bar at 23°C), Eq. ( 2) becomes:

up l v P F K Q  (4)
The pressure recovery factor Fl can be seen as a measure of the valve performance loss due to cavitation. It is inferior or equal to 1. Equation ( 4) is used with the results of the series at full cavitation to estimate it.

Hydraulic forces

In a fully turbulent flow without cavitation, the ratio between fluid force load and pressure drop is theoretically constant, homogeneous to a surface and it is called the hydraulic surface Sh:

down up h P P F S   ( 5
)
Where F is the fluid force load (N).

Equation ( 5) is used with results obtained without cavitation and, even if it does not theoretically apply in such conditions, it is also used here with results at full cavitation to enable a comparison. For information, when the valve is closed, depending if the seat inner or outer diameter is considered, the area on which water exerts pressure is 7.3 × 10 -4 or 8.3 × 10 -4 m 2 .

Fig. 5 shows the hydraulic surface computed for every case. At high opening, there is no significant difference between the curves, whereas at low lift, the well-known ring effect is demonstrated and the fluid flow load increase drastically as the valve closes between 0 and 2 mm.

Fig. 5 Hydraulic surface comparison

For the low values of lift, interactions between the disc valve and the ring up induce a back pressure on the lateral section of the disc increasing the force applied on the disc.

Cavitation has a less important effect. Slightly lower values are observed without cavitation between 0 and 1.5 mm lift for the lower ring position and between 4 and 5.5 mm for the upper one.

NUMERICAL APPROACH

Computational domain and meshing strategy

The computational domain is defined from the geometrical model shown in The mesh is built with ICEM and is only composed of hexahedral elements based on a structured topology [Fig. 7]. It is particularly refined near the valve disc in order to assess the hydrodynamic forces with accuracy. When the valve lift is modified, the structured grid is updated by moving the blocking topology around the valve disc. The mesh size reaches 1.3 million cells. Following the lift position, the average value of y + is comprised with 10 and 15 on the valve disc surface; specific cell thickness progression laws between the disc and the nozzle are applied to ensure good grid quality and near wall orthogonality is enforced. The meshing characteristics are given following the table 1 for two lift positions.

Boundary conditions and model definition

Numerical simulations are carried out with ANSYS CFX 13.0. Among the eighteen valve lifts studied experimentally, only four have been simulated: 1, 3, 6 and 8.4 mm. The interpretations of the numerical simulations are really difficult for low valve lifts, typically lower than 1 mm. Indeed, when the disc gets close to the nozzle, instable phenomena difficult to take into account may appear. Moreover, the mesh quality cannot be ensured while keeping a reasonable grid size. So it becomes very hard to reproduce such phenomena with the numerical model. But the aim of the present study is not to deal with the transient behavior so the lowest lift for the simulation is limited at 1 mm. The four operating points have been simulated assuming steady state approach and the residuals of all equations reaches 10 -4 . As cavitation is not taken into account in the numerical simulations, the discharge coefficient of the SRV does not depend on the flow rate value. So the inlet condition is given by a uniform flow rate value and a static pressure is imposed at the outlet location. All the simulations are performed under smooth wall conditions.

Turbulence boundary conditions

The choice of the turbulent input conditions can be very important given the turbulence model used. The default input conditions for turbulence depends a lot on the computational software used. For example, with ANSYS CFX, the dissipation scale is by default set such that:

10    t ( 6
)
where t is the turbulent eddy viscosity and  the kinematic viscosity. This setting creates too low values of turbulent dissipation at the inlet which limit the production term downstream, near the point of impact flow. Furthermore, these conditions do not correspond to fully-developed turbulent pipe flow. In order to reproduce correct input conditions, the dissipation scale is modified with the standard equation ( 7),

h D k 3 . 0 2 3   (7)
where k is the turbulent kinetic energy, Dh is the hydraulic diameter.

Turbulence modelling: description and analysis

This part does not aim to give improvements to model the turbulent flow but explanations are given to understand the behavior of the different turbulent models applied on the SRV application. If k- modeling is used, the k production term reaches unrealistic values after the impact zone. The turbulent intensity becomes thus too high [fig. 8]. This behavior is well-known because two equations models do not take into account the redistribution of Reynolds stress towards the pressure gradient [START_REF] Durbin | On the k- Stagnation Point Anomaly[END_REF].

Fig. 8 Turbulent intensity computed with the k- model for 3 mm lift

In SST approach the model coefficients are switched from k- variables in the inner region of the boundary layer to k- variables in the outer region [START_REF] Menter | Ten Years of Industrial Experience with the SST Turbulence Model[END_REF], thanks to the first blending function F1 which is F1 = 1 in the near-wall region and F1 = 0 in the outer region. It was usually conceded that the k- model is better than the k- model in predicting adverse pressure gradient flows because it predicts a smaller shear stress [START_REF] Davidson | Hybrid LES-RANS modeling: a one-equation SGS model combined with a k- model for predicting recirculating flows[END_REF].

But, as it is, the predicted shear stress stays too large. So a limitation of the eddy viscosity is introduced to improve the modeling behavior [START_REF] Menter | Ten Years of Industrial Experience with the SST Turbulence Model[END_REF]. This effect can be observed by plotting the coefficient Cµ [fig. 9] required to compute the turbulent viscosity and which becomes with the SST model:

           2 31 . 0 , 09 . 0 min F C (8) Where S k   
is the strain rate parameter, S is the shear strain rate and F2 is the second blending function for SST modelling. Equation ( 8 In order to demonstrate the effect of the eddy viscosity limiter, the different behavior of turbulent models can be demonstrated by using the realizability condition of [START_REF] Behnia | Prediction of heat transfer in an axisymmetric turbulent jet impinging on a flat plate[END_REF][START_REF] Durbin | Limiters and wall treatments in applied turbulence modeling[END_REF].

In first approximation, by keeping only the normal stress in the primary direction, we can write the following realizability relation:

0 3 2 2 11 1 1     k S u u t  (9)
Where

              i j j i ij x U x U S 2 1
is the strain rate tensor.

  0   ii S U div
and under the previous assumptions Eq. ( 9) about the normal stress, the following inequality is given:

3 2 3 1 11 S S S S ji ij   (10)
Considering Eq. ( 10), a simplified criterion easy-toplot [Fig. 11] can be defined:

1 3  k S t  (11)
Then the over-estimation of turbulent kinetic energy in the stagnation points is pointed out by the regions where the realizability criterion is not satisfied. Figure 11 shows the non-realizability of the k- modeling near the disc which impacts greatly the overall characteristics of the relief valve. Nevertheless, the behavior of the k- modeling is acceptable in the seat region. It seems that the improvement of the predicted flow is not due to the k- formulation but thanks to the eddy viscosity limiter acting at the stagnation point.

Flow coefficient Kv and hydraulic surface

Figure 13 compares the discharge coefficients Kv, as defined earlier (1), obtained from numerical results and experimental measurements. Concerning the large lifts (L/d>0.2), the numerical results and the experimental data are very well correlated while for the lowest lift the numerical simulations tend to overestimate the discharge coefficient. This effect cannot be explained by possible cavitation appearance because no performance drop has been experimentally observed for the low valve lifts (Fig. 4). In fact, the experimental behaviour showing an inflection point when the location of the minimal section changes (0.2<L/D<0.25) is not numerically predicted. Steady state computations of the lowest lifts have shown that the convergence curve is much noisy. A transient approach for these operating points could improve the numerical predictions.

Fig. 13 Comparison of the discharge coefficients

Figure 14 compares the hydraulic surfaces Sh, as defined earlier Eq. ( 5), obtained from numerical results and experimental measurements. Numerically, the hydrodynamics forces are evaluated considering all the surfaces of the valve disc by integrating the pressure distribution and the friction contribution. The numerical solutions under-estimate the experimental results by around -10% for every lift.

Prediction of possible cavitation locations

The objective of this section does not aim to propose two-phase flow modeling in order to predict the onset of cavitation. Instead the idea is to analyze the pressure field from an easier to produce single-phase flow to detect possible cavitation locations. The only interest in using a cavitation model based on a mechanical approach (by using Rayleigh-Plessey modeling for example) is in the description of the unsteady behavior; but it is not the objective of this study. So in first approximation, it is possible to estimate where cavitation could appear by plotting negative values of the variable Pv which is defined as:

sat down v P P P P    ( 12
)
where Pdown is the upstream pressure and Psat is a critical pressure which can be equal in a first approximation to the water saturation pressure Pvap.

Pvap is a function of temperature. It is equal to 0.028 bar at 23°C. Figure 15 shows the possible cavitation locations for 3 mm valve lift and upstream pressure Pdown = 4 bar.

With this definition given by Eq. ( 12) cavitation due to the effects of shear strain near the valve disc is not represented. The turbulence effects on cavitation development can be taken into account by modifying the value of Psat as Ait Bouziad (2006):

S P P t vap sat ) (      (

CONCLUSION

Experiences have been performed in order to investigate the influence of the ring position and cavitation on the hydraulic characteristics of safety relief valves. Without cavitation and considering the experimental operating conditions, we observed that the upper ring position increases the discharge coefficient Kv of about 10% for intermediate valve lifts. It also significantly increases (up to 70%) the hydraulic forces on the disc at low lifts. Considering that during the experiment, the vaporization pressure was close to zero, cavitation shows limited influence, it only cancels the discharge coefficient increase when the ring is up. The free cavitation results have been used to validate numerical modeling of turbulent single-phase flow through the safety relief valve.

The behavior of several turbulent modeling based on two-equation RANS simulations has been explained. In particular, a viscosity limiter has to be used to predict correctly the turbulent production close to the stagnation point of the valve.

In this study numerical simulations using SST modeling have been performed with ANSYS CFX and accurate predictions of discharge coefficients and hydraulic load have been obtained according to experimental results.

Fig. 1

 1 Fig. 1 The scale model built in Plexiglas 2.2 Experimental devices / instrumentations

Fig

  Fig. 3 Flow visualization. Up: intermediate cavitation, down: slow motion screenshot 3. EXPERIMENTAL RESULTS

Figure 4

 4 Figure 4 compares the Kv, Kv Fl and Fl obtained from experimental results. They are plotted by dimensionless heights L/D where L is the lift and D is the nozzle diameter. Whatever the ring position the flow coefficient curves exhibit an inflection point where the slope becomes negative. Then it is shown two regimes representing on the flow coefficient curves by two different linear trends. It can be explained by the location of the minimal section of the flow: if L/D is lower than 0.25 the minimal section isgiven by the lateral section (DL) but when L/D is larger than 0.25 the minimal section is given by the nozzle diameter (D2/4). This effect depends on the ring position because it is reduced with the ring down position. Moreover, it is correlated with the decreasing of the Fl values which reach a local minimum near L/D~0.2. Similar results have been already observed in[START_REF] Pinho | Experimental study of two-phase flow induced by cavitation through a safety relief valve[END_REF] considering 1 ½ G3 SRV and 2J3 SRV. Nevertheless, for full cavitation conditions, the ring position does not show any effect, whereas for the no-cavitation conditions, its upper position causes a flow rate overshoot (0.15<L/D<0.25).

Fig. 4

 4 Fig. 4 Flow characteristics obtained experimentally at different openings; comparisons of Kv and KvFl (a) and liquid recovery Factor Fl for the ring up position (b)

Fig. 7

 7 Fig. 6 Safety relief valve H and geometrical simplifications for computational domain

  ) allows to switch from Cµ = 0.09 (k- model coefficient) to lower values following the dissipation scale and the strain rate parameter The prediction of the turbulent intensity with the SST model is shown in Fig. 9. The abnormal peak of turbulent kinetic energy observed with the k- simulations [Fig. 8] is reduced thanks to the viscosity limitation near the stagnation region [fig. 9 (b)]. This limitation is due to the second blending function F2 of the SST model as is shown on figure 10. Nevertheless, the viscosity cut induced by the Cµ decreasing is controlled by the shear strain rate S which grows up dramatically in this region.

Fig. 9

 9 Fig. 9 Turbulent intensity computed with the SST model (top) and Cµ coefficient (bottom) for 3 mm lift Using the continuity equation for incompressible flows

  Fig. 10 Second blending function F2 (a) and strain rate parameter η (b)

Fig. 11

 11 Fig. 11 Realizability criterion with k- model (a) and SST model (b) -inlet turbulence with hydraulic diameter Any two-equation turbulent model based on an eddy viscosity limiter would allow to obtain similar numerical results; especially as the limiter is controlled by the strain rate parameter as shown in Fig. 12 and ensures the realizability constraint (Durbin (2009), k- realizable Park (2005), k--Cas Uribe et al.(2006)). As a consequence, the k- SST model is kept for all computational cases.

  Fig. 14 Comparison of the hydraulic surface Sh

Fig. 16

 16 Fig. 16 Possible location of cavitation appearance with Pcav modified by (13) for valve lift 3 mm (a) and 6 mm (b), at Pdown = 4 bar Moreover, post-processing analysis has been proposed to detect possible cavitation locations. The qualitative representation of these possible locations seems to be in good agreement with the experimental visualizations. The next step lies on the development of cavitation modeling using Rayleigh Plessey model aiming to reproduce the performance drop due to cavitation observed for intermediate valve lifts induced by.

Table 1 Mesh characteristics

 1

		Angle	Skewness
		Min 99% >	Min	99% >
	1mm lift	14° 27°	0.17	0.35
	6mm lift	18° 27°	0.2	0.45