Gustavo Sousa

Walter Rudametkin

Laurence Duchien

Extending Dynamic Software Product Lines with Temporal Constraints

Keywords: variability, dynamic software product lines, feature models, cloud computing, 1

Due to the number of cloud providers, as well as the extensive collection of services, cloud computing provides very flexible environments, where resources and services can be provisioned and released on demand. However, reconfiguration and adaptation mechanisms in cloud environments are very heterogeneous and often exhibit complex constraints. For example, when reconfiguring a cloud system, a set of available services may be dependent on previous choices, or there may be alternative ways of adapting the system, with different impacts on performance, costs or reconfiguration time.

Cloud computing systems exhibit high levels of variability, making dynamic software product lines (DSPLs) a promising approach for managing them. However, in DSPL approaches, verification is often limited to verifying conformance to a variability model, but this is insufficient to verify complex reconfiguration constraints that exist in cloud computing systems.

In this paper, we propose the use of temporal constraints and reconfiguration operations to model a DSPL's reconfiguration lifecycle. We demonstrate how these concepts can be used to model the variability of cloud systems, and we use our approach to identify reconfigurations that meet given criteria.

I. INTRODUCTION

In the cloud computing paradigm, computing resources are delivered to customers as services at different levels of abstraction, such as infrastructure, platform and software [START_REF] Mell | The NIST definition of cloud computing[END_REF]. Each cloud computing provider offers a different set of services, such as processing power, network communication, virtual machines, containers, software packages, application servers, databases, development and management tools, etc. When deploying an application to the cloud, customers can select a set of services to build a cloud environment that supports their applications' requirements.

However, cloud providers are very heterogeneous, and each provider may have a different set of complex rules governing the selection of services. To deal with this complexity, recent works [START_REF] Quinton | SALOON: a platform for selecting and configuring cloud environments[END_REF], [START_REF] Sousa | Automated setup of multi-cloud environments for microservices applications[END_REF], [START_REF] García-Galán | Automated configuration support for infrastructure migration to the cloud[END_REF], [START_REF] Ferreira Leite | Automating resource selection and configuration in inter-clouds through a software product line method[END_REF] have proposed the use of software product line (SPL) techniques, such as feature models, to capture the variability of cloud configurations, allowing the automated setup of cloud environments. The cloud computing model also supports rapid provisioning and release of resources [START_REF] Mell | The NIST definition of cloud computing[END_REF], providing mechanisms for reconfiguring an existing environment to cope with new application requirements or context changes. The high variability in cloud configuration, together with the support for dynamic provisioning, makes dynamic software product lines (DSPLs) a promising approach to build adaptive cloud environments.

However, mechanisms offered for adapting cloud environments may differ substantially between providers, and complex constraints may also apply to reconfigurations. Depending on providers, the same context or requirements change may require a different set of reconfiguration operations. Even within the same provider, multiple alternative ways of performing the same reconfiguration may be offered, each one with a different impact on performance, costs and downtime. Additionally, choices made in the initial or previous configurations may affect the set of available future reconfigurations, thus changing the system's variability over its lifecycle. In a sense, reconfigurations in cloud systems are not stateless, they depend on the system's current and past configurations, but this information is not captured in DSPLs.

Previous work on DSPLs [START_REF] Morin | Models@run.time to support dynamic adaptation[END_REF], [START_REF] Hubaux | On the evaluation and improvement of feature-based configuration techniques in software product lines[END_REF] highlight the importance of guaranteeing a safe transition from a valid initial configuration to a target configuration. However, in most DSPL approaches verification is restricted to checking if a target configuration complies to its variability model. In existing approaches, there is no regard about how the system transitions between configurations, if there are any constraints over these transitions, or if multiple alternatives are available.

In this paper, we propose extending feature models with temporal constraints and reconfiguration operations to model the variability of DSPLs. We introduce reconfiguration operations to enable describing multiple alternative reconfiguration paths, together with their associated costs. We demonstrate how principles from model checking can be used to implement reasoning over these concepts, allowing us to check for reconfiguration request validity and to find reconfigurations that meet a specific criteria (e.g., downtime, costs). Finally, we evaluate our approach with a use case on adaptive cloud computing environments.

In Section II, we discuss the motivation for using temporal constraints in dynamic software product lines for cloud computing. In Section III, we define the semantics of temporal logic constraints and reconfiguration operations on feature models. Section IV describes the implementation of a tool for automated reasoning over feature models with temporal constraints and reconfiguration operations. Finally, we discuss related work in Section VI and the conclusions in Section VII.

II. MOTIVATION

When a cloud environment is initially setup for an application, it is conceived to support initial application requirements. However, as application requirements evolve or the system load changes, its environment should be reconfigured to deal with these new requirements. These changes may include the provisioning of extra resources such as virtual machines or application containers when more requests arrive, or upgrading to a larger database plan as the system starts having more users, or changing the application framework to cope with application evolution.

Systems that exhibit runtime variability as the cloud environments are candidates for employing a DSPL architecture. DSPLs leverage concepts and engineering foundations from SPL to support the construction of adaptive systems [START_REF] Hallsteinsen | Dynamic software product lines[END_REF]. The core element of both approaches is a variability model that specifies variation points in which members of a product line can differ. Feature models are widely used to model variability in product line approaches, and many methods for their automated analysis are available [START_REF] Benavides | Automated analysis of feature models 20 years later: A literature review[END_REF].

In DSPL approaches, feature models may be enriched with context [START_REF] Mauro | Context aware reconfiguration in software product lines[END_REF] and binding time [START_REF] Lee | A feature-oriented approach to developing dynamically reconfigurable products in product line engineering[END_REF], [START_REF] Capilla | Binding Time and Evolution[END_REF], [START_REF] Bürdek | Staged configuration of dynamic software product lines with complex binding time constraints[END_REF] information. A reconfiguration is usually triggered by monitored context features or another system component requesting the inclusion (exclusion) of a set of features to (from) the current configuration. Techniques for automated analysis of feature models are then used to verify if the requested configuration is valid according to feature model structure and constraints. Once a target configuration is validated, adaptation mechanisms from the underlying platform (e.g. component models, reflection, models@runtime) are used to enact the it.

However in cloud computing, reconfiguration mechanisms may vary according to the provider, and even for the same provider different services may have different reconfiguration support. While some services may have their settings updated at runtime, others may require a service restart or still a complete redeployment of the service.

A. Motivating example

To illustrate the problems faced while managing variability and adaption in cloud environments we present an example from the Heroku PaaS provider. The feature model in Fig. 1 describes part of the variability in the configuration of Heroku PaaS. In Heroku, users can define application projects that include support for development in a given programming language such as Java, Ruby or PHP and a set of additional cloud services such as databases, caching, monitoring tools, etc. The cloud customer can choose in which geographical region (US or EU) he wants the application project to be deployed and cloud services may be available at different plans (M1, M2, H1, H2, S1, S2, etc), with different capabilities and costs.

While initially setting up an application project, customers have access to all cloud services, and can select any configuration that complies with the feature model. However, after the initial setup, reconfigurations may be limited by the initial 5and therefore implies a series of complex operations. This may include the migration of application code and data. Similar to the examples above, this can be achieved in different ways by combining different operations, with different effects on costs, downtime and performance of the application during migration. Even from this simple example, we can notice that cloud environments may be subject to complex constraints governing when and how a new configuration can be reached. Existing DSPL approaches do not provide enough support for modeling or reasoning over reconfigurations constraints and are restricted to verification of the structural variability.

B. Challenges

We wish to provide support for automated reasoning on reconfigurations in cloud systems. To do so, we require modeling the constraints and reconfiguration operations of a cloud system in a way that allows for a generically, independent of cloud providers. In this paper, we investigate how reconfiguration constraints can be added to feature models to support modeling and reasoning over cloud environments adaptation. More specifically, we try to tackle the following challenges.

• Model temporal constraints on DSPLs. How to define constraints that include temporal aspects, such as when selecting a feature makes another feature unavailable for all future reconfigurations? • Model reconfiguration operations and constraints How to capture multiple alternative reconfiguration paths and their impact on performance, costs and reconfiguration time? • Finding reconfigurations How to implement reasoning over feature models and reconfiguration constraints to answer queries such as 'what is the cheapest reconfiguration path to meet a set of requirements' or 'is there a reconfiguration path in which there is no downtime?'.

III. MODELING DSPL ADAPTATION Previous works [START_REF] Hubaux | On the evaluation and improvement of feature-based configuration techniques in software product lines[END_REF], [START_REF] Morin | Models@run.time to support dynamic adaptation[END_REF] on DSPL highlight the need for adaptive systems to perform safe transitions between configurations. According to Morin et al. [START_REF] Morin | Models@run.time to support dynamic adaptation[END_REF], systems should evolve through a safe migration path between configurations, while Hubaux et al. [START_REF] Hubaux | On the evaluation and improvement of feature-based configuration techniques in software product lines[END_REF] say that transitions should not only consider static constraints of a variability model but also the "dynamic constraints that determine the allowed transitions between configurations".

In spite of it, existing works on DSPLs provide little support for reasoning over transitions between configurations. In most approaches, verification is limited to checking if a target configuration conforms to a variability model.

In some approaches, the variability model is augmented with context features [START_REF] Mens | A taxonomy of context-aware software variability approaches[END_REF], [START_REF] Capilla | Context variability for contextaware systems[END_REF], [START_REF] Capilla | Collaborative context features for critical systems[END_REF], [START_REF] Mauro | Context aware reconfiguration in software product lines[END_REF] or binding time [START_REF] Lee | A feature-oriented approach to developing dynamically reconfigurable products in product line engineering[END_REF], [START_REF] Bürdek | Staged configuration of dynamic software product lines with complex binding time constraints[END_REF] information. Still, verification is restricted to monitoring context changes, checking what features need to be (de)selected and verifying if these features can be rebound at runtime.

According to [START_REF] Cetina | Autonomic computing through reuse of variability models at runtime: The case of smart homes[END_REF], [START_REF] Morin | Models@run.time to support dynamic adaptation[END_REF], [START_REF] Saller | Context-aware dspls: Model-based runtime adaptation for resource-constrained systems[END_REF] a DSPL can be abstracted as a reactive transition system [START_REF] Baier | Principles of Model Checking (Representation and Mind Series)[END_REF] in which states represent valid system configurations and state transitions define system adaptations. The variability model is therefore a compact notation for describing a DSPL's transition system. By using a variability model we eliminate the need to enumerate all possible system configurations and transitions.

However, as a variability model abstracts away from its underlying transition system, it fails to capture any restriction that may exist on the transitions between configurations. By introducing temporal constraints and reconfiguration operations we give first class status to these transitions while looking for a compromise between full specification of a transition system and the more abstract view based on variability models.

A. Preliminary definitions

In the following paragraphs, we will go over definitions for feature models, transition systems and DSPLs. Then, we will introduce temporal constraints and reconfiguration operations to DSPLs.

Definition 1: A feature model can be defined as a tuple M = (F, P ) where F is the set of features and P ⊆ P(F) is the set of valid products that can be derived from the feature model. We also use the [[M ]] F M notation to denote the set of products of a feature model M .

Definition 2: A transition system [START_REF] Baier | Principles of Model Checking (Representation and Mind Series)[END_REF] can be described by a Kripke structure [START_REF] Schneider | Verification of Reactive Systems: Formal Methods and Algorithms[END_REF] T = (S, I, R, AP, L) where S is a finite set of system states, I ⊆ S is the set of initial states, R ⊆ S×S is a left-total relation representing state transitions, AP is a set of propositions and L : S → 2 AP is a labeling function. An execution path of T is a non-empty infinite sequence of states ρ = s 0 , s 1 , s 2 , s 3 , ... such that s 0 ∈ I and (s i , s i+1 ) ∈ R for all i ≥ 0. The behavior of a transition system t is defined by the set all possible execution paths, denoted by [[T ]] T S ⊆ S ω where S ω is the set of all infinite sequences of states in T .

Definition 3: Given a feature model M = (F, P ), the corresponding DSPL can be represented as a transition system DSP L(M ) = (S, I, R, AP, L) where

I = S = P , R = S × S, AP = F and L(s) = s.
From this definition, a DSPL can be seen as transition system in which each state represents a possible configuration according to the feature model. The system can start at any configuration and transition to any other possible configuration.

B. Temporal constraints

A temporal property [START_REF] Manna | A hierarchy of temporal properties[END_REF] defines a condition over the execution paths of a transition system. A system is said to satisfy a given property if all of its possible execution paths satisfy the property. Thus, a temporal property specifies the admissible or desired behavior of a system over time.

Definition 4: Let T = (S, I, R, AP, L) be a transition system, a temporal property P ⊆ S ω over T is a set of execution paths over the states of T . The transition system T satisfies the property P , written

T |= P iff [[T ]] T S ⊆ P .
Temporal properties are commonly used in model checking [START_REF] Baier | Principles of Model Checking (Representation and Mind Series)[END_REF] to verify if a system exhibits a certain behavior, but can also be used to specify how the system should behave. Adding temporal properties to DSPL specification, allows to constrain the transitions between configurations to only those that satisfy the property. Thus, by combining feature models with temporal constraints we can define more precisely the adaptive behavior of a DSPL.

The semantics of a transition system and temporal properties are defined by sets of execution paths over system states. Transition systems and properties can be treated as languages over the set of system states. The execution paths are infinite words over the alphabet Σ = S. Thus, given a transition system T S, we say L(T S) is the language that represents all possible executions of T S. Similarly, for a property P , L(P ) is the language that represents all the possible executions that satisfy P . The intersection of L(T S) ∩ L(P ) is the set of execution paths of T S that satisfy P .

Therefore, given a feature model M and a set of properties φ ⊆ P(S ω ), we want to build a transition system T S DSP L such that

L(T S DSP L ) = x∈φ L(DSP L(M )) ∩ L(x).
That is a transition system whose execution paths are infinite sequences of configurations for feature model M that conform to all temporal properties φ.

Linear temporal logic (LTL) [START_REF] Baier | Principles of Model Checking (Representation and Mind Series)[END_REF] is one of the most commonly used formalisms for expressing temporal properties and can represent a subset of the class of ω-regular properties. ω-regular properties correspond to the class of ω-regular languages, an extension of regular languages to infinite words.

In our work, we employ LTL as a formalism for defining temporal constraints, but other notations [START_REF] Baier | Principles of Model Checking (Representation and Mind Series)[END_REF] could also be used applying the same principles. In LTL, formulas are composed of a finite set of atomic propositions AP , boolean connectors such as ¬, ∧, ∨, →, and temporal logical operators U (until), (next time), (always) and (eventually). Given p ∈ AP , the syntax of an LTL formula can be defined by the following grammar:

φ ::= p | ¬φ | φ ∧ φ | φ ∨ φ | φ → φ | φ Uφ | φ | φ | φ
Besides the standard boolean logic operators, LTL temporal operators can be defined in terms of the (next) and U (until) operators. The intuitive semantics of these operators is that φ means that proposition φ should hold in the next state of a path. Thus the formula φ ∧ ψ defines the φ should hold in the current state and ψ should hold in the next state. The until operator defines that a a proposition should hold until another becomes true. Therefore φ U ψ means that φ should hold from now on up to when ψ becomes true.

When defining temporal constraints over feature models the set of atomic propositions is defined by the set of features. Thus, an atomic proposition is true at a given state if the corresponding feature is selected in the corresponding configuration.

Using LTL we can express some constraints shown in the motivating example in Section II-A. For example, in the case of constraints on downgrading MySQL database plan, we could use the following LTL formula to define that a configuration using plan M 2 cannot be downgraded to use M 1.

(M 2 → ¬ M 1)
Actually, this constraint expresses that if at any point in time ( ), if the system goes though a state in which M 2 is selected, then M 1 should not eventually (¬ ) be selected in the future.

As part of the class of ω-regular languages, LTL formulas are closed under union and intersection. Thus, given LTL formulas φ and ψ, L(φ) ∩ L(ψ) = L(φ ∧ ψ).

From an LTL formula φ, we can build a corresponding Büchi automaton A φ that accepts exactly the infinite sequences of states that comply with φ. Büchi automata are an extension of finite automata for ω-regular languages and thus can be composed with a transition system to obtain another transition system that represents the intersection of both languages.

Thus, given a feature model and a temporal constraint, we can define a DSPL transition system whose execution paths are sequences of feature model configurations that conform with the temporal constraint.

Definition 5: Given a feature model M and a LTL formula φ, we can build DSPL with temporal constraints as DSP L(M, φ) = DSP L(M ) ⊗ A φ . That is, the synchronized product between the transition system for the DSPL defined by M , and the Büchi automata for φ.

As discussed earlier, a feature model M defines a corresponding transition system DSP L(M ) in which there are transitions between any two possible feature model configurations. The goal of including temporal constraints is to limit these transitions and express the actual variability of the system over time.

By combining a feature model with temporal constraints we can define a DSPL's adaptive behavior in a compact way. Temporal constraints can be defined using well-known LTL logical formalism, which can be transformed into a Büchi automaton and combined with the feature model into a transition system.

C. Reconfiguration operations

In the previous section we introduced temporal constraints to feature models to define properties over a DSPL's adaptive behavior. For the analysis of temporal properties, we did not consider any actions or labeling of transitions and analysis was strictly state-based.

However, as seen in the motivating example, reconfiguring a cloud environment may require executing some operations such as migrating a database, restarting services, redeploying an application project, etc. Each of these operations may have different impacts on the application cost and performance, and therefore should be considered during the reconfiguration process.

For modeling a DSPL with reconfiguration operations we rely on the definition of doubly labeled transition systems (L 2 T S) [START_REF] Beek | An Action/State-Based Model-Checking Approach for the Analysis of Communication Protocols for Service-Oriented Applications[END_REF], in which both states and actions can be labeled with atomic propositions. In the literature, other similar notations such as labeled Kripke structures [START_REF] Chaki | State/Event-Based Software Model Checking[END_REF] and mixed transition systems [START_REF] Pecheur | Symbolic Model Checking of Logics with Actions[END_REF] have also been used for state/actionbased analysis.

Definition 6: A L 2 T S is a tuple T = (S, I, Act, R, AP, L) where S is a finite set of system states, I is the set of initial states, Act is a finite set of transition actions, R ⊆ S×2 Act ×S is the transition relation, AP is a set of atomic propositions and L : S → 2 AP is a state-labeling function.

An execution path of t is an infinite sequence of states and sets of actions ρ = s 0 , α 0 , s 1 α 1 , s 2 , α 2 , s 3 , ... such that s 0 ∈ I and (s i , α i s i+1 ) ∈ R for all i ≥ 0.

This definition extends Kripke structures with a set of actions that can be part of a transition. In the context of a DSPL these actions represent reconfiguration operations required to adapt the system from a current configuration to a new desired configuration.

An L 2 TS enables describing a DSPL's transition system considering reconfiguration operations. However, as mentioned earlier, completely specifying a DSPL transition system is unfeasible due to the large number of states and potential transitions. As in the case of temporal constraints, it would be more valuable to have a declarative language that enables describing in which cases reconfiguration operations are needed.

State/Event Linear Temporal Logic (SE-LTL) [START_REF] Chaki | State/Event-Based Software Model Checking[END_REF] is an extension of LTL to support expressing temporal properties over states and actions. SE-LTL is very similar to LTL, but allows for temporal logic state/event formulas over state atomic propositions and actions. Given p ∈ AP and a ∈ Act, the syntax of an SE-LTL formula is defined by the following grammar:

φ ::= p | a | ¬φ | φ ∧ φ | φ ∨ φ | φ → φ | φ Uφ | φ | φ | φ
Semantics differ slightly as an SE-LTL property may also include constraints over actions. In these cases, an action holds at a given state in an execution path if it is part of the transition immediately after it. Thus, given an execution path ρ = s 0 , α 0 , s 1 , α 1 , s 2 , ... , action a ∈ Act holds at state i iff a ∈ α i . Note that the transition relation R ⊆ S ×2 Act ×S is defined over the power set of actions and each transition can have multiple actions. The semantics of logical and temporal operators is the same as in LTL.

Using the SE-LTL we can express constraints from the motivating example given in Section II-A that involve operations and features. For instance, we could express the rule that changing the geographical region requires migrating the application as follows:

(((U S ∧ EU ) ∨ (EU ∧ U S)) → M igrateApp)
This constraint defines that whenever the location feature is changed from U S to EU or vice-versa, the M igrateApp operation should be executed. Therefore, by employing SE-LTL we can define temporal and propositional constraints over features and reconfiguration operations.

Considering temporal constraints and reconfiguration operations we can redefine the syntax and semantics of DSPLs based on a feature model.

Definition 7: Given a feature model M = (F, P ) and a set of reconfiguration operations OP, we can define the corresponding DSPL as a doubly labeled transition system such that DSP L(M, OP ) = (S, I, Act, R, AP, L), where

I = S = P , Act = OP , R = S × 2 OP × S, AP = F and L(s) = s.
This definition extends DSPLs based on a feature model with a set of reconfiguration operations. The obtained transition system allows transitioning between any feature model configuration by executing any combination of reconfiguration operations. As in the case of LTL formulas, SE-LTL can also be used to build a Büchi automaton [START_REF] Chaki | State/Event-Based Software Model Checking[END_REF] that can be combined with the transition system obtained from the feature model and reconfiguration operations to limit the allowed transitions.

Definition 8: Given a feature model M , a set of reconfiguration operations OP and a SE-LTL formula φ, we build a transition system DSP L(M, OP, φ) = DSP L(M, OP ) ⊗ A φ .

That is the synchronized product, as defined in [START_REF] Chaki | State/Event-Based Software Model Checking[END_REF], of the transition system obtained from the feature model and reconfiguration operations with the Büchi automaton that accepts the property defined by the formula φ.

D. Reconfiguration operation costs

Reconfiguration operations may result in downtime, performance loss, or additional costs during reconfiguration. In our motivating example, migrating a PostgreSQL database using pgcopy requires about 3 minutes of downtime per GB according to Heroku documentation. However, syncing a follower database may take hours, and adds the expense of a second database, but has minimal to no downtime.

To calculate the cost of applying a reconfiguration, we assume that cloud providers supply a set of cost functions C = {c 0 , c 1 , c 2 , c 3 , ...}, where each function c i ∈ C is specific to a type of cost (e.g., downtime, performance penalty, monetary cost) and takes as argument any reconfiguration operation op ∈ OP .

Since many cost functions require access to the current system configuration and load, we feel that providers are in the best position to provide such functions. However, many cost functions can be created, as we have done, by studying the provider's documentation. These serve as utility functions that can be used to optimize a higher-level fitness function that is written by the user. Furthermore, the units returned by a cost function (e.g., seconds, dollars, percentage) don't need be standardized, nor do the same cost functions need to be applied across providers. Because users will invoke this functions explicitly, we only require that the user understand the function, the units returned by the function, and how to interpret them.

Introducing temporal constraints on DSPLs enables us to express detailed constraints on how variability can be applied to the system over its lifetime. Reconfiguration operations allow describing and analyzing the different ways of effecting a reconfiguration, as well as making explicit the constraints between features and operation. Finally, cost functions provide a means of understanding the side-effects of reconfigurations and for optimizing the user's extra-functional requirements, such as downtime or cost. Together these constructs support modeling adaptation constraints in cloud environments that cannot be captured with variability models.

IV. REASONING ON DSPL ADAPTATION

The previous section presented how we define a DSPL as a transition system, and how temporal constraints can be combined with feature models to better capture a DSPL's adaptation behavior over time. In this section we discuss implementing a reasoner for identifying a reconfiguration plan given a reconfiguration request.

A. Reconfiguration query

Adaptations in a DSPL are usually triggered by requests to include or remove a set of features from the current configuration, or by changes in monitored context features. In both cases, we have a current system configuration and a high-level change request that specifies which features should be included or excluded. From these, we want to identify the set of possible reconfigurations that will move the system to a target state that conforms to the requested change. In addition, according to system preferences, we may also be interested in finding a reconfiguration that meets some criteria, such as having no downtime or minimizing costs.

Definition 9: A reconfiguration query q = (A, E, ψ) is defined by a set A of features that should be part of the target configuration, a set E of features that should not be part of the target configuration, and a condition ψ over the reconfiguration transition. This condition can be defined over reconfiguration cost functions. Given c ∈ C and i ∈ N, a condition is defined over the following grammar:

ψ ::= ¬ψ | ψ ∧ ψ | ψ ∨ ψ | ψ → ψ | c relop i relop ::= ≤ | < | > | ≥ | =
A condition ψ defines a predicate over transitions based on the estimated costs of executing their reconfiguration operations. Thus, given a condition ψ = c relop i, we have the predicate g ψ over 2 Act defined as

g q (α) = α ⊆ Act ∧ a∈α c(a) relop i
For conditions that employ logical operators (i.e. ∧, ∨, ¬, →) we can obtain a corresponding predicate by applying these operators to predicates over costs accordingly.

Similarly, from feature sets A and E, we can also define a predicate over the set of states S of a transition system that recognizes candidate target configurations as

f q (s) = s ∈ S ∧ A ⊆ L(s) ∧ (E ∩ L(s) = ∅)
Given a transition system T = (S, I, Act, R, AP, L), its current state s and reconfiguration query q = (A, E, ψ), we can define the set of possible reconfigurations as

N T (s, q) = {(α, s ) | (s, α, s ) ∈ R ∧ g q (α) ∧ f q (s )}
A reconfiguration includes a target state and a set of reconfiguration actions for moving the system to the target states. The reconfigurations returned by function N T are those for which the target states and reconfiguration actions comply with the predicates defined by the reconfiguration query. Example

B. Optimization query

Besides finding a set of possible reconfigurations for a given query, one may be interested in identifying optimal reconfigurations. with minimum monetary costs or downtime.

Definition 10: An optimization query o = (q, φ) is defined by a reconfiguration query and an objective function φ. The objective function φ : OP → N can be defined as composition of cost functions c ∈ C. Given a transition system T = (S, I, Act, R, AP, L), its current state s and an optimization query o = (q, φ), we can define the set of optimal reconfigurations as O T (s, o) = min (α,s )∈N T (s,q) a∈α φ(r) .

C. Symbolic representation

What's symbolic representation: From a system current configuration and reconfiguration query, we are interested in finding one or many possible target configurations. From the transition system of a DSPL, we can identify what are the possible reconfigurations by looking at the transitions outgoing the current system state and searching for the ones that agree with the reconfiguration query. However, as discussed earlier, explicitly building a DSPLs transition system can be unfeasible due to the large number of possible states and transitions.

One approach to deal with this problem is to build a symbolic representation of the transition system. The idea behind symbolic representation is to represents sets of system states and the transition relation as a propositional formula. Set operations can then be effected as logical operations between formulas and set membership by solving satisfiability. Thus, the set of states of a transition system can be defined by a propositional formula over the set of atomic propositions using substantially less space than the number of possible states.

A feature model can also be seen as a symbolic representation of the set of valid configurations for a system.

A model with n features can describe a system with up to 2 n possible configurations. In addition, a feature model can also be represented as a propositional formula [25], for which the satisfiable assignments represent the set of valid configurations.

Let T = (S, I, Act, R, AP, L) be a transition system, the transition relation R ⊆ S × 2 Act × S can be defined by a propositional formula over AP ∪ Act ∪ AP . For representing a transition system as a propositional formula we need to define two sets of propositional variables, representing the set of atomic propositions AP at the source and target states. Here we have AP = {p | p ∈ AP } as a copy of atomic propositions that represent the labeling in a target state. Besides this, we have to consider transition actions that may occur between any two states, represented by Act.

For each state in a transition system, the labeling function L : S → 2 AP defines exactly what are the atomic propositions that hold at a given state. For any state s ∈ S, we may define a propositional formula that uniquely identifies this state as

L(s) = ( p∈L(s) p) ∧ ( p∈(AP \L(s)) ¬p).
Similarly, every transition (s, α, t) in the transition relation R ⊆ S × 2 Act × S has a set of transition actions a ∈ α. For any set of transition actions, we may define a propositional formula that uniquely identifies it as

L(α) = ( a∈α a) ∧ ( a∈(Act\α) ¬a).
Relying on these functions that uniquely identify a set of actions and a state, we can define a transition relation by the following propositional formula

R t = (s,α,t)∈R L(s) ∧ L(α) ∧ L(t) .
Thus, from any state s ∈ S the set of outgoing transitions can be obtained by the propositional formula P ost(s) = R t ∧ L(s).

Based on this we can obtain a propositional formula that represents the set of transitions that can be obtained by a reconfiguration query. So, given a reconfiguration query q = (A, E, ψ) and current state s, we can obtain the propositional formula

P ost(s, q) = L(s) ∧ ψ ∧ ( p∈A p ) ∧ ( p∈E ¬p )
that defines the set of transitions from state s that are according to query q. By solving satisfiability over the formula we can find the reconfiguration alternatives that support are according to query.

Here, we showed how we can represent a transition system symbolically by a propositional formula and use satisfiability solver to find a set of transitions that support a given query. However, we are not interested in building a symbolic representation from a complete transition system, but directly from a feature model extended with temporal constraints and reconfiguration operations.

As mentioned earlier, if we do not consider temporal constraints, a DSPL defined by a feature model can transition between any two valid configurations. So, given a feature model M , we have a propositional formula M that defines the set of allowed configurations [[M ]] F M and a set of operations OP , we can define the propositional formula for the transition relation as

R F M = M ∧ OP ∧ M .
An LTL formula can also be transformed into a propositional formula [START_REF] Clarke | Another look at ltl model checking[END_REF], [START_REF] Cimatti | Improving the Encoding of LTL Model Checking into SAT[END_REF], that symbolically defines an equivalent transition relation. The obtained propositional formula is defined over the atomic propositions included in the formula, which in the DSPL case can be features or operations. From an LTL formula φ, we obtain a propositional formula I φ that defines the set of states in which φ holds and R φ that defines the transition relation. Thus, from a feature model M and an LTL formula φ we can obtain the propositional formulas I M φ = m ∧ I φ that represents the set of valid configurations at the initial state, and

R M φ = m ∧ m ∧ OP ∧ R φ
that represents the set of allowed transitions between system states. Similarly, the set of valid transitions from a given current state s is defined by the formula

P ost M φ (s) = L(s) ∧ R M φ .
Once we have a propositional formula that represents the set of valid transitions from a current state, we can use a SAT solver to find what are the possible transitions. So, given a reconfiguration query q = (A, E, ψ) without any optimization goal or cost constraints (ψ = true), we can obtain a valid transitions by finding a satisfiable assignment to the formula

P ost M φ (s, q) = L(s) ∧ R M φ ∧ ( p∈A p ) ∧ ( p∈E ¬p ).
If there are cost constraints (ψ = true), we can use support from Pseudo-Boolean SAT solvers [START_REF] Philipp | PBLib -A Library for Encoding Pseudo-Boolean Constraints into CNF[END_REF] for encoding linear inequalities as boolean constraints. Similarly an optimization request can be encoded using Pseudo-Boolean SAT optimization [START_REF] Boros | Pseudo-boolean optimization[END_REF].

Symbolic representation of transition systems enables to express the sets of states and the transition relation as a propositional boolean formula. From a given feature model and LTL formula, we can obtain a corresponding transition system as well as its symbolic representation. Given a reconfiguration query, we can use SAT solvers to reason over the system's symbolic representation and identify a valid transition from a current state.

V. EVALUATION

To assess the use of temporal constraints and reconfiguration operations in DSPLs, we evaluate them in the context of a case study on the Heroku PaaS provider. Our goal is to validate the feasibility of the proposed approach in modeling configuration constraints of cloud providers, as well as the performance of evaluating reconfiguration requests.

A. Tool implementation

Before presenting the evaluation results, we give a brief overview of our implementation of the proposed approach.

To support specifying a DSPL, we designed a domainspecific language to define feature models with cross-tree

/ * Feature Model * / Heroku { Application { Location [ US | EU | PrivateLocation [ Virginia | Oregon | Frankfurt | Tokyo | Sydney ] ] Process? { Buildpack [ Ruby | Node | Clojure | Python | Java | Gradle | Grails | Scala | Play | PHP | Go ] Kind [ Web | Worker ] Size [ Free | Hobby | Standard1X | Standard2X | PerformanceM | PerformanceL ] } Addons? { HerokuPostgres? [ HobbyDev | HobbyBasic | Standard0 | Standard2 | Premium1 | Premium2 ] ClearDBMySQL? [ Ignite | Punch | Drift | Scream ] / * ... * / } } } / * ... * / } / * Temporal constraints * / []( (Punch -> X!Ignite) && (Drift -> X!(Punch || Ignite)) && (Scream -> X!(Drift || Punch || Ignite)) ) []( Change(ClearDBMySQL) -> UpgradeMySQL ) []( Change(Location) -> MigrateApp )
[]( (Change(HerokuPostgres) && (Switch(HobbyDev) || Switch(HobbyBasic))) -> PgCopy ) []( Change(HerokuPostgres) -> (PgCopy || FollowerPgDb) ) Fig. 2. Sample extract from Heroku feature model constraints on features, and temporal constraints on both reconfiguration operations and features. From the feature diagram and cross-tree constraints, we generate a propositional formula that correspond to a symbolic representation of the set of valid configurations for the DSPL. From temporal constraints, described as LTL formulas, we also obtain a symbolic representation of the DSPL's transition relation. These are then combined into propositional formulas that describe the DSPL's transition system as defined in Section IV. In both cases, we implemented well-known algorithms presented in previous work [25], [START_REF] Clarke | Another look at ltl model checking[END_REF], [START_REF] Cimatti | Improving the Encoding of LTL Model Checking into SAT[END_REF].

To perform perform a reconfiguration or optimization query, we convert the query into a propositional formula that represents the set of valid reconfigurations that comply with the query. We then find candidate reconfigurations by solving satisfiability over the combined formulas of the query and the DSPL's transition system.

As described in Section IV, the symbolic representation of transition systems enables to express the sets of states and the transition relation as a propositional boolean formula. We use the SAT4J 6 solver and the LogicNG7 library for encoding Pseudo-Boolean constraints that involve cost functions. The implementation was largely written in Groovy with smalls parts in Java.

B. Case study

For our case study we designed a feature model containing the features and constraints described in Section II. which was augmented with data extracted from the Heroku website.

We obtained information on 161 addon cloud services from different categories, such as data storage, networking, security, management tools, etc. We automatically extracted, from each addon's webpage, the information on service plans, region availability and language support. From region availability information, we generated cross-tree constraints for 113 services that are not available in every region. Similarly, 66 constraints were generated from language support information. Additionally, for each addon with multiple service plans we generated a reconfiguration operation, and a corresponding temporal constraint, associating the operation to changing the addon plan.

The resulting Heroku feature model consists of 1036 features, 124 operations, 134 cross-tree constraints and 124 temporal constraints. We also defined two cost functions, price and downtime. that estimate, respectively, the monetary cost and the downtime of performing a reconfiguration operation. Fig. 2 shows an extract from this feature model, defined in the domain-specific language that was designed as part of our tool implementation. The extract includes a part of the feature model hierarchical structure as well as some temporal constraints between feature changes and reconfiguration operations.

C. Experimental setup

To evaluate reconfigurations in Heroku PaaS environments, we designed a set of 4 adaptation scenarios, defined in Table I, that represent example adaptations. For each scenario, we executed 5 different kinds of queries, including restrictions and optimizations on price and downtime. These experiments were run for 3 different utilization profiles that represent application metrics at the moment a reconfiguration is triggered. In our experiment, we considered application and database size, as well as application startup time. These metrics are used because they affect reconfiguration costs, but other information available from the executing environment could be used, in conjunction with new operation cost functions, as well.

For each combination of adaptation scenario, query and utilization profile we measured the time required to find one valid reconfiguration. Besides this, we also measured the time required to build a symbolic representation of a DSPL transition system from the Heroku feature model. We executed 12 times each combination, leading to a total of 720 individual query evaluations. All experiments were run on a late 2013 MacBook Pro Laptop with a 2 GHz Intel Core i7 processor and 8GB of memory.

D. Results

In Table II we present the minimum, maximum and average times of executing each of the measured processing operations. The first line shows the time required to build a symbolic representation of the transition system, which includes the time to translate the feature model diagram and LTL formulas into propositional formulas. The second line shows the time required to find a valid reconfiguration from a given query. This includes the time to translate the query into a propositional formula and solve satisfiability. The following lines shows results for executions grouped by the kind of query. As defined in Table I, we have reconfiguration queries without cost constraints (1), with cost constraints (2, 3) and optimization queries [START_REF] García-Galán | Automated configuration support for infrastructure migration to the cloud[END_REF][START_REF] Ferreira Leite | Automating resource selection and configuration in inter-clouds through a software product line method[END_REF].

The process step that required the most time was the construction of a symbolic representation for the transition system (average of 8777ms). However, this representation only needs to be built once and can then be used for executing multiple reconfiguration queries. From analysis of the execution times for reconfiguration queries we can see that those including constraints on cost functions are the ones that required more time to be executed (average of 225.78ms). This is mainly due to the time required to encode Pseudo-Boolean constraints on cost functions as propositional formulas. For the other kinds of queries, most of time is spent on solving the boolean satisfiability problem that we encode. Fig. 3, shows a distribution of execution time for different kinds of queries. From this chart, we can see that queries 2 and 3, that rely on cost constraints take substantially longer than other kinds of queries. Besides this, queries that combine different cost functions (3 and 5) take usually longer than with just one cost function ( 2 and4).

E. Threats to validity

The feature model for Heroku used in our evaluation was built from information obtained through documentation and structured data available on their website. This means the variability and constraints considered may not be exhaustive and there might be new constraints that are not supported by our approach. Also, the cost functions defined for our experiments return arbitrary values. More realistic cost functions should rely on better information retrieved from the cloud environment and the current configuration. Nevertheless, more precise cost functions (e.g., that return a better estimate), would not affect the performance or the modeling capacity of the approach since we only rely on the return values.

We evaluated our approach using one case study that applies to cloud computing. And although we have identified similar concerns in other systems where temporal constraints exist and are not modeled using unified or homogeneous mechanisms, we have not evaluated our approach in these cases. Hence, we are optimistic that our approach is applicable to other providers, to other scenarios, and to other domains, but this must be verified.

VI. RELATED WORK

Featured Transition Systems are a variant of transition systems designed to describe the combined behavior of an entire system family [START_REF] Classen | Model checking lots of systems: Efficient verification of temporal properties in software product lines[END_REF], [START_REF] Legay | Featured transition systems: Foundations for verifying variability-intensive systems and their application to ltl model checking[END_REF]. Temporal logic is used for defining properties to be checked against systems that are part of a Software Product Line (SPL). However, their goal is to use model checking to verify temporal properties over a family of related systems, while ours is to define the adaptive behavior of a Dynamic Software Product Line (DSPL).

In many DSPL approaches, variation points are augmented with binding time information [START_REF] Capilla | Binding Time and Evolution[END_REF] to specify when features can or must be (de)activated, such as during compilation, configuration, start-up, runtime, etc. In [START_REF] Bürdek | Staged configuration of dynamic software product lines with complex binding time constraints[END_REF], Bürdek et al. propose an approach for defining constraints over binding times, making it possible to indirectly define some temporal properties through constraints between features and binding times. However, in cloud environments, each cloud service may exhibit a different and independent lifecycle, and temporal constraints are not limited to binding time.

In [START_REF] Cetina | Using feature models for developing self-configuring smart homes[END_REF], reconfiguration actions are used to update a system's architecture as a result of a dynamic reconfiguration. This concept is similar to reconfiguration operations used in our approach, but there is no support to evaluate the costs of actions nor to reason over multiple alternative reconfiguration paths.

In Genie [START_REF] Bencomo | Genie: Supporting the model driven development of reflective, component-based adaptive systems[END_REF], variability models are combined with transition diagrams that define how a system can adapt between its different variants. However, when the number of system variants is very large, fully defining its transition diagram can quickly become unfeasible. In our work, we employ temporal logic notation to define a system's allowed transitions, which enables to define the adaptive behavior in a declarative way.

In [START_REF] Aguirre | A temporal logic approach to the specification of reconfigurable component-based systems[END_REF], authors propose to use temporal logic for specifying reconfigurable component-based systems. Similar to our work, temporal logic is used to declaratively define how a system can be reconfigured.

A few recent works propose the use of DSPLs to manage adaptive cloud systems. In [START_REF] Almeida | Dynamic adaptation of cloud computing applications[END_REF] and [START_REF] Metzger | Coordinated run-time adaptation of variability-intensive systems: An application in cloud computing[END_REF], variability from applications and their running cloud environment are combined to build systems that can adapt their behavior and executing environment. In [START_REF] Baresi | Dynamically evolving the structural variability of dynamic software product lines[END_REF], authors propose an architecture for changing the structure and configuration options of feature models at runtime, allowing the dynamic evolution of the system's variability. Their work is also motivated by a cloud computing scenario.

Our approach shares with previous work the use of variability models and transition systems to support the modeling and management of adaptive systems. However, as cloud environments offer heterogeneous adaptation mechanisms there may also be complex constraints governing when and how a system can be adapted. Our work differs from previous work by combining variability models with temporal logic to support a declarative definition of adaptive systems with complex adaptation constraints.

VII. CONCLUSION

In this paper we propose the use of temporal constraints on variability models, which allows specifying a Dynamic Software Product Line's adaptive behavior. The need for temporal constraints arised from the complex reconfiguration constraints that we identified when managing the lifecycle of adaptive cloud systems. We integrated temporal properties and reconfiguration operations into the definition of DSPLs to support expressing these constraints and reasoning over them to find valid adaptations when a context change is identified.

Based on concepts from model checking, we implemented a tool for checking a reconfiguration query against the current system configuration. Our tool finds valid target configurations, as well as sets of reconfiguration operations required to update the cloud environment to the target configurations. We evaluated the approach with a use case for the Heroku PaaS cloud provider. The approach enabled us to define many existing constraints that were not supported by previous DSPL approaches and reason over them with low performance overhead. The prototype implementation and results can be found in the accompanying site 8 .

We plan to investigate how these concepts can be applied to build multi-cloud adaptive environments, that is, cloud systems composed of services operating across different providers. In this case, reconfigurations may involve multiple providers and the system needs to coordinate multiple DSPLs with different variability and adaptation constraints. Another research direction is to use temporal properties to support variability evolution in cloud providers. As temporal properties define the allowed transitions in a system, they could be used to define valid reconfigurations for running systems when structural variability is updated.

Fig. 1 .

 1 Fig. 1. Partial feature model for the Heroku PaaS provider

TABLE II RESULTS

 II

				Execution time (ms)
	Process step		Avg	StdDev Min Max #Exec
	Build Trans System 8777.31 303.71 8262 10308	720
		-Process FM		244.75	28.57	191	552
		-Process LTL		8533.57 291.81 8025 10023
	All Queries		183.34	50.20	118	389	720
		-Build		83.05	50.69	27	227
		-Solve		100.29	37.13	5	200
	Q wo/ Constraints	140.97	12.93	118	198	144
		-Build		32.73	4.56	27	48
		-Solve		108.24	11.58	90	153
	Q w/ Constraints	224.23	55.55	128	389	288
		-Build		140.41	27.65	80	227
		-Solve		83.82	53.13	5	200
	Q w/ Optimization	163.63	13.26	136	230	288
		-Build		50.85	7.11	38	77
		-Solve		112.77	10.21	94	166
		400
		350
		300
	Time (ms)	250
		200
		150
		100
		Query	1	2	3	4	5
					Query
	Fig. 3. Distribution times for executing each query 144 times (4 scenarios
	× 3 profiles × 12 runs)

https://devcenter.heroku.com/articles/app-migration

http://www.sat4j.org/

https://github.com/logic-ng

https://devcenter.heroku.com/articles/cleardb# upgrading-your-cleardb-database 2 https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases 3 https://devcenter.heroku.com/articles/buildpacks# setting-a-buildpack-on-an-application [START_REF] García-Galán | Automated configuration support for infrastructure migration to the cloud[END_REF] https://devcenter.heroku.com/articles/scaling#scaling-the-dyno-size


Emilie Steiner

Mehdi Yemloul

Laouès Guendouz

Sébastien Leclerc

Anthony Robert

Daniel Canet
email: daniel.canet@crm2.uhp-nancy.fr

NMR relaxometry : spin lattice relaxation times in the laboratory frame versus spin lattice relaxation times in the rotating frame

Relaxometry dispersion curves display the spin lattice relaxation rate as a function of the measurement frequency. However, as far as proton NMR is considered, dispersion curves usually start around 5 kHz and thus miss the very low frequency region. This gap can be filled by the measurement of the spin-lattice relaxation rate in the rotating frame. The issue of connecting both relaxation rates is considered for two relaxation mechanisms: i) randomly varying magnetic fields, ii) dipolar interaction within a system of two equivalent spins. Appropriate data processing is presented and the random field mechanism turns out to be adequate.

Introduction

Measurement and interpretation of NMR relaxation times as a function of the measurement frequency 0  (or, equivalently, as a function of the NMR static magnetic field 0 B through the Larmor equation

0 0 B   
,  being the gyromagnetic ratio of the considered nucleus) is called relaxometry. Applications are numerous [START_REF] Kimmich | NMR -Tomography, Diffusometry, Relaxometry[END_REF] ranging from the characterization of slow molecular motions in complex systems to the effects of paramagnetic species on biological fluids. Dedicated instruments, called relaxometers (working according to field cycling methodology), are available in a range going from some kHz (say 5 kHz) to some tens of MHz (typically from 10 MHz to 40 MHz). Higher frequencies can be investigated with conventional NMR spectrometers, possibly with variable field electromagnets in the range 10 MHz-100 MHz, or at still higher frequencies with fixed frequency cryomagnets. Results, in terms of the longitudinal relaxation rate 1 R (the inverse of the relaxation time 1 T ), are usually presented in the form of a so-called dispersion curve, 1 R being the ordinate (with a logarithmic scale if variations are important) and the measurement frequency as abscissa (generally with a logarithmic scale). These dispersion curves present a gap in the frequency range going from zero frequency up to some tens of kHz. The present study is devoted to the way of filling this gap which can contain important information about slow motions or exchange phenomena.

One possibility, explored in this paper, is to measure the so-called relaxation time in the rotating frame ( 

1 T or its inverse  1 R ) as a function of 1 1 B    where 1
B is the amplitude of the radio-frequency (rf) field along which nuclear magnetization is locked (measuring this relaxation time is accomplished by following the decay of locked magnetization). However, the major concern is that  1 R does not depend on 1  in the same way as 1 R depends on 0  [2,3]. Indeed, in the case of diamagnetic systems, in only one instance [4] (to the best of our knowledge) was the  1 R dispersion curve directly linked to the 1 R dispersion curve. It can be mentioned that, in the case of paramagnetic relaxation enhancement (PRE), Fries et al.

recently proposed [5] to use a linear combination of 1 R and  1 R . The approach presented here is along the same lines and could be applied to systems which possess a slow electronic spin relaxation [6], thus not overwhelming the low-frequency

 1 R dispersion. Otherwise  1 R has
been mostly used to characterize very slow motions [7,8] or exchange phenomena in biological systems through 15 N [9][10][11][12][13][14] or proton [15] measurements. It must be noticed that, in order to increase the frequency range, off-resonance experiments, first introduced by Desvaux [16], were employed [8,[11][12][13][14][15]. This adds however some complexity in the exploitation of experimental data.

The present work is devoted to a transformation of  1 R data so that they can complement the 1 R dispersion curve toward the very low frequencies. Obtaining a full dispersion curve presents obviously some advantages in terms of the accuracy of parameters derived from dispersion curves and may reveal relaxation mechanisms undetectable at higher frequencies.

Exchange phenomena will not be envisionned here. The proposed procedure will be considered theoretically and two examples will be given: one dealing with a solvent in interaction with the surface of an organogel, the protons of this solvent being subjected in addition to a constant contribution due to paramagnetic relaxation, the other with the different types of water in a mesoporous medium.

Theory

The expressions of the three relaxation rates we are concerned with here (the spin-lattice or longitudinal 1 R , the spin-spin or transverse 2 R , the spin-lattice in the rotating frame  1 R )

depend obviously on the relaxation mechanisms. We shall be dealing exclusively with dipolar interactions experienced by the proton(s) of the molecules under investigation. Two situations can be envisioned: i) interactions arise from outside; in that case randomly fluctuating magnetic fields constitute a good approximation for evaluating the spectral densities entering the expression of relaxation parameters; ii) interactions take place inside the set of the considered protons (e.g. the dipolar interaction between the two protons of the water molecule) and one has to take heed of the whole system (constituted of "like spins", according to Abragam's terminology [START_REF] Abragam | The Principles of Nuclear Magnetism[END_REF]) and, as will be seen below, this entails some complications.

Of course, the present treatment rests on the hypothesis of classical dipolar interactions and would probably need some modifications in the case of a quantum magnetic moment, e.g. a paramagnetic ion [START_REF] Belorizky | [END_REF].

Equations given below are expressed in terms of spectral densities [START_REF] Kowalewski | Nuclear Spin Relaxation in Liquids: Theory, Experiments and Applications[END_REF][START_REF] Canet | Nuclear Magnetic Resonance: Concepts and Methods[END_REF], their simplest form being

2 2 1 2 ) ( c c J       (1)
where c  is a correlation time describing a motion supposed isotropic. Of course, the expressions below can accommodate any type of spectral density.

Random fields

0  and ' 0  being measurement frequencies, one has for the three relaxation rates

other R J C R   ) ( 2 ) ( 0 0 1   (2) other R J J C R    )] ( ) 0 ( [ ' 0 2  (3) other R J J C R    )] ( ) ( [ ) ( ' 0 1 1 1     (4)
C stands for a factor including constants and the amplitude of the relevant dipolar interaction while other R stands for the contribution of other relaxation mechanisms. 0  represents the low frequencies at which 1 R is measured, just above (or overlapping with) the frequency range covered by the

 1 R measurements. ' 0
 is the frequency (relatively high for sensitivity reasons) of the spectrometer with which these latter measurements have been carried out. [START_REF] Look | [END_REF] arises from the correlation function of the random field transverse components (x and y), hence the 0  dependency which corresponds to the precession of the two homolog magnetization components. Conversely, ( 3) and ( 4) depend on one transverse component and of the longitudinal component (z). The latter is responsible for the spectral density at zero frequency (no precession) in (3) and at 1  (nutation around the rf field) in ( 4). It can be noticed that the only difference between

 1 R and 2 R is the substitution of ) 0 ( J by ) ( 1  J .
From equations ( 2) and ( 4), it is obvious that, in non extreme narrowing conditions, ) (

1   R cannot be equal to ) ( 1  R . ) ( 1   R
can however be processed according to the following algebra. Consider the frequency b 1  in the region where

 1 R and 1 R overlap. We can always write ' ) ( 2 ) ( 2 1 1 1 C R CJ R other b b       (5)
with the constant ' C defined as

other b b R CJ R R C     ) ( 2 ) ( ) ( 2 ' ' 0 1 1 1 1     (6)
Consider now a frequency a 1  where only  1 R is available. In order to compare and eventually to connect 1 R and  1 R data, the latter must be substituted by ' 1 R which we define as

' ) ( 2 ) ( 1 1 1 ' 1 C R R a a       (7) ) ( 1 ' 1 a R   should therefore be identical to ) ( 1 1 a R  .
Measurements of  1 R are performed for different values of 1  (by varying the amplitude of the rf field). According to equation (7), they are then multiplied by two and subtracted by a quantity independent of 1  and corresponding to ) ( 2 ' 0  J and to other contributions to the relaxation rates, constant at these low frequencies. In practice, this quantity is determined by making coincident, in the overlap region, the two dispersion curves

) ( 0 1  R and ) ( 1 1   R
. Of course, the rf field amplitude cannot be made infinitely small. Fortunately, ) 0 ( J is better deduced from the measurement of 2 R to which the above treatment can be applied as well.

Like spins

With the same notations as in the previous section, one has [START_REF] Look | [END_REF]3,[START_REF] Abragam | The Principles of Nuclear Magnetism[END_REF][START_REF] Kowalewski | Nuclear Spin Relaxation in Liquids: Theory, Experiments and Applications[END_REF][START_REF] Canet | Nuclear Magnetic Resonance: Concepts and Methods[END_REF]

other other R CJ R J J C R      ) 3 ( 5 )] ( ) 2 ( 4 [ 0 0 0 1    (8) other R J J J J C R       )] ( 2
3 ) 2 ( ) ( 6
1 ) 0 ( 3 2 [ ' 0 ' 0 ' 0 ' 0 2     ( 9
) other R J J J J C R       )] ( 2
3 ) 2 ( ) ( 6
1 ) 2 ( 3 2 [ ' 0 ' 0 ' 0 ' 0 1 1       (10)
The approximation in equation ( 8) which consists in replacing

) ( ) 2 ( 4 0 0   J J  by ) 3 ( 5 0  J
has been shown to be very appropriate [START_REF] Koenig | [END_REF]. The somewhat complicated expressions of 2 R and  1 R are due to the existence, in a two-spin system, of a two-quanta coherence (hence the spectral densities at 0 2 or ' 0 2 ) and a zero-quantum coherence (emphasized here by ) ( ' 0 ' 0   

J

which has not the same physical meaning as ) 0 ( J ). There are some important differences with respect to the random field mechanism:

) 0 ( J in 2 R becomes ) 2 ( 1  J in  1 R while 1 R depends on ) 3 ( 0  J
. This means that the procedure described in the previous section can be applied with a multiplicative factor of 15/2 (in place of 2) and provided that the frequency scale is adapted to each parameter:

0 3   for ) ( 1  R and 1 2   for ) ( 1   R .

Experimental

Two systems presently under investigation in this laboratory, with the objective of obtaining full dispersion curves, i.e. from zero up to several hundreds of MHz, were retained for the present study. However, as we are concerned here with the very beginning of the dispersion curve, we shall focus only on the frequency range 0-10 MHz. The first one is the solvent (toluene) necessary to the formation of an organogel built with a modified amino-acid [22];

the problem is to know whether, once the gel is formed, toluene still interacts with its surface (experiments performed at 20°C). An unexpected complication occurs due to dissolved oxygen in pure toluene, providing a strong paramagnetic contribution to relaxation rates [23].

At the time the organogel was prepared, we were not aware of this problem which would anyway be difficult to overcome due to the actual preparation procedure. Fortunately, this paramagnetic contribution is constant at low frequencies and can be simply subtracted thus permitting to examine unambiguously the effects of the toluene-gel interaction. On the other hand, due to the number of interacting protons and because it is the total proton magnetization of toluene which is measured, a random field mechanism can be predicted.

The second system is water within a mesoporous medium. In that case, one could wonder if the dipolar relaxation mechanism is intramolecular (the like spins model would prevail) or intermolecular or both. As further discussed in the conclusion, a random field mechanism will be shown to constitute a good approximation for the two latter cases. Anyway, the problem is to characterize, on the one hand, water inside pores, which presumably manifests itself at low frequencies due to a long correlation time, and, on the other hand, interstitial water, which is expected to contribute predominantly at high frequencies due to a smaller correlation time (experiments performed at 25°C). However, for such a system, the whole dispersion curve must be considered and its behavior at very low frequencies can be important for its global analysis.

Proton longitudinal relaxation times were first measured with a Stelar (Mede, Italy) Smartracer relaxometer operating between 5 kHz and 10 MHz according to field cycling automatic procedures [24]. This instrument requires 10 mm o.d. NMR sample tubes which were therefore utilized for subsequent measurements (so as to investigate the very same sample). A home-made spectrometer operating at 200 MHz was employed for 

1

T and 2 T measurements. A special probe, accommodating 10 mm o.d. sample tubes (see above) and capable of handling relatively high rf power for a relatively long time (spin lock periods), was specially constructed. It involves a saddle-shaped coil of 29 mm height and 14.5 mm diameter (silver coated copper wire of 1.5 mm diameter) for covering a substantial portion of the sample with a homogeneous rf field, and high voltage 0.8-10 pF variable non magnetic capacitors (RP series, Polyflon, Norwalk, CT). Its quality factor is of 470. As a matter of fact, problems were encountered, not with the probe but with the stability and possible droops of the power amplifier. This prevents to go beyond 13 kHz (the rf field amplitude being expressed in frequency units) with durations of the spin-lock period up to 6s. This seemingly modest performance (as compared to a previous probe designed for 5mm o.d. sample tubes [25]) is due to the unfavorable coil geometry adapted to the 10mm o.d. sample tubes.

 1
T was deduced from the decay of the locked magnetization [19,20] under on-resonance conditions, implying two distinct experiments in the case of toluene, one for the methyl and the other for the aromatic resonances. The spin locking field amplitude is varied from experiment to the other and calibrated from the duration of a 180° rf pulse. 2 T was measured according to the CPMG method [26] in order to compensate imperfections of the 180° rf pulses and with a sufficient number of pulses in order to reduce diffusion effects, which, due to background gradients, could be important in the case of porous media [START_REF] Kimmich | NMR -Tomography, Diffusometry, Relaxometry[END_REF].

Results and discussion

Figure 1 shows toluene raw data in the range 1 kHz-10 MHz (  1 R , 1 R ) for the pure solvent and for the solvent in the organogel phase. In both cases, one observes, as expected, a plateau at very low frequencies in accord with the first part of a Lorentzian curve (see eq. ( 1)). In the case of pure toluene, this plateau extends beyond 10 MHz and is attributable to paramagnetic relaxation [23]. Conversely, in the gel phase, the rise beneath 10 MHz is characteristic of a hindered motion, attributable to the interaction with the organogel. The rescaling of  1 R data against 1 R data has been carried out as explained in the theory section according to the random field model. This is shown in figure 2. Owing to these excellent results, it was deemed unnecessary to try the other model (like spins). On the other hand, 2 T could actually be measured for the methyl resonance but not for the aromatic resonance because of the echo modulation by spin-spin couplings. Thus, the determination of the global 2 R turned out to be impossible. This was not considered as a penalty since  1 R data just confirm the plateau guessed from 1 R data.

The other system dealt with in this study is water in a mesoporous medium [27]. Figure 3 shows the raw 1 R and  1 R data obtained at 25° C. In figure 4, the  1 R data have been rescaled

according to the random field model so as to coincide with 1 R data in the overlap region. The consistency of both sets of data is seen to be excellent. Conversely, an attempt to rescale  1 R data according to the like spins model (see above) is seen to fail (figure 5). Moreover, as shown in figure 6, 2 R appears to be in perfect agreement with what should be  1 R at zero frequency (see equations ( 3) and ( 4)). This demonstrates the consistency of all relaxation data

( 1 R ,  1
R and 2 R ). For this system, we have therefore at hand the whole dispersion curve from zero frequency up to several hundreds of MHz (not shown). Indeed, it will be confirmed in a future work that the data at very low frequencies are essential for properly analyzing dispersion curves.

Conclusion

This study has demonstrated the possibility of obtaining dispersion curves in the whole frequency range, including zero frequency (in the absence of J couplings) and very low frequencies. At least for the two investigated systems (very different in nature), the random field model appears perfectly adequate for linking 1 R and  1 R evolutions. Besides a change in the frequency scale which is almost the same for 1 R and  1 R data and, thus, is not very significant, the major difference between the random field model and the like spins model lies in the multiplicative factor which is applied to  1 R data: 2 for the former model 15/2 for the latter. As a matter of fact, the failure of the like spins model is not very surprising because it applies strictly to a system made of two isolated spins, a situation which is rarely encountered.

Indeed, it can be shown that this property could be extended to a multi-spin system if and only if all the cross-relaxation rates are identical. Figure 2. Filled squares: 1 R data of Toluene in the organogel phase (20° C, identical to fig. 1). Open squares :  1 R data rescaled for coinciding with 1 R data in the overlap region (see text). Figure 4. Filled squares: 1 R data of water in a porous medium (25° C, identical to fig. 3). Open squares :  1 R data rescaled for coinciding with 1 R data in the overlap region (according to the random field model, see text).

Figure 1 .

 1 Figure 1. Raw data of pure Toluene (20° C). Filled triangles: 1 R . Open triangles :  1 R . Raw data of Toluene in the organogel phase (20° C). Filled squares: 1 R . Open squares :  1 R .

Figure 3 .

 3 Figure 3. Raw data for water in a porous medium (25°C). Filled squares: 1 R . Open squares:  1 R .

Figure 5 .

 5 Figure 5. Same as figure 4 but with the like spins model showing the inadequacy of the model. Note the modifications of the frequency scales according to the procedure detailed in the text.

Figure 6 .

 6 Figure 6. Same as figure1with normal ordinate and abscissa scales (and reduced frequency range) permitting to display the 2 R value (triangle at zero frequency).

1 )Figure 6

 16 Figure 1

Acknowledgements

We are grateful to Alain Retournard and Pierre-Louis Marande for technical assistance. This work is part of the ANR project "Instrumentation in Magnetic Resonance" (Grant Blan06-2_139020) and also of the ANR project MULOWA (Grant Blan08-1_325450).

The thorough analysis of the manuscript by an anonymous referee and its subsequent improvement are gratefully acknowledged.