Duo Wei

Vincent Dorcet

Christophe Darcel

Jean-Baptiste Sortais

Synthesis of quinolines via acceptorless dehydrogenative coupling catalyzed by rhenium PN(H)P complexes

Keywords: quinoline, rhenium, hydrogen borrowing, acceptorless dehydrogenative coupling

A practical and sustainable synthesis of substituted quinolines was achieved via the annulation of 2-aminobenzyl alcohol with various secondary alcohols, ketones, aldehyde or nitriles, under hydrogen borrowing conditions. Under the catalysis of well-defined rhenium complexes bearing tridentate diphosphinoamino ligands, the reaction proceeds efficiently (31 examples with isolated yields up to 96%) affording a diversity of quinoline derivatives.

N-heterocycles are ubiquitous skeleton in natural products and biologically active molecules. [START_REF] Joule | Heterocyclic Chemistry[END_REF] Among this family, substituted quinolines are extensively used in pharmaceuticals, medicinal chemistry, [2] agrochemicals, and functional materials. [3] Accordingly, new synthetic protocols are continuously needed to access a large diversity of functionalized quinolines. Conventional routes for the preparation of quinolines, [START_REF] Joule | Heterocyclic Chemistry[END_REF] such as Skraup [START_REF] Skraup | [END_REF] , Camps [5] and Knorr [6] synthesis, have been reported over a century ago. However most of these methods suffer from multiple steps synthesis, harsh conditions (high temperature, excess of bases or acids) and low chemoselectivity leading to overall low yields and poor atom economy. [START_REF] Keller | Comprehensive Heterocyclic Chemistry III[END_REF] Among those synthetic approaches, the Friedländer reaction has been proven to be one of the simplest and most efficient methods. [START_REF] Marco-Contelles | [END_REF] Although the Friedländer method is quite versatile, the primary limitation of this approach is the preparation and stability of the starting materials, i.e. 2-aminobenzaldehyde derivatives, since these compounds undergo easily self-condensation. To overcome these limitations, the indirect Friedländer reaction, involving the oxidative annulation of stable 2aminobenzylalcohols with either readily available secondary alcohols or ketones, via hydrogen auto-transfer reactions, is a powerful and sustainable way to access quinolines. [9] Several catalytic systems based on group 8 to 10 transition metals (Ru, [10] , Rh, [11] Pd, [12] Ir, [13] , Au [14] , Cu, [15] , Co [16] ) have been developed. In particular, our group reported the first non-noble metal catalyzed Friedländer annulation reaction using iron Knölker-type complexes. [17] It is also worth noting that stoichiometric amount of bases are also able to promote metalfree indirect Frieländer reactions. [18] By contrast, group 7 transition metal based catalysts have just emerged very recently as suitable metals for promoting hydrogen borrowing reactions. [19] Manganese catalysis for (de)-hydrogenation reactions has grown exponentially over the last two years. [20] Nevertheless, to date, only three catalytic systems are reported for the synthesis of quinolines, two of which are using over-stoichiometric amount of bases. [21] On the opposite, hydrogen auto-transfer reactions catalyzed by rhenium are still quite rare. [22] Recently, we have developed a series of rhenium complexes with the tridentate PN(H)P ligands (Scheme 1, A-E), which are efficiently employed in the hydrogenation of carbonyl derivatives [23] and mono N-methylation of anilines with methanol as C1 source. [24] In the meantime, Beller's group independently reported hydrogen auto-transfer and related dehydrogenative coupling reactions to form α-alkylated ketones and substituted pyrroles, using the same rhenium PN(H)P pincer complex A. [25] Inspired by these recent developments in the area of synthesis of N-heterocycles and following our interest in hydrogenation [20m, 26] and hydrogenation borrowing reactions [27] based on group 7 transition metal complexes, we described hereafter the first example of synthesis of quinolines via acceptorless dehydrogenative coupling catalyzed by rhenium catalysts in the presence of a catalytic amount of base. Scheme 1. Rhenium PN(H)P complexes involved in this study.

Initially, we selected 2-aminobenzyl alcohol (1a, 1.0 equiv.) and 1-phenylethanol (2a, 1.0 equiv.) as a benchmark system for the dehydrogenative cross-coupling formation of 2phenylquinoline. It is worth noting that all the reactions were performed with a stoichiometric ratio between the two coupling partners. To our delight, complexes A, B and C showed excellent reactivity (Table 1, entries 1-3) at a catalyst loading of 5 mol% in toluene at 140 °C for 24 h in the presence of catalytic amount of t-BuOK (10 mol%), giving respectively 88%, 87% and, 90% yields. Not surprisingly, complexes D and E, bearing the more steric hindered PNP ligands, and the precursor Re(CO)5Br were not active, (Table 1, entries 4-6) which is in line with the reactivity already observed for the mono N-methylation of anilines. [24] The conditions of the reaction were further optimized with catalyst C (1 mol%) at 150 °C: various bases were tested (Table 1, entries 7-10), showing that t-BuOK was the best candidate, giving 87% yield. Further decreasing of the amount of base to 5 or 2 mol% led to lower yields, 74% and 50% respectively (Table 1, entries 13 and14). Two blank reactions, in Supporting information for this article is given via a link at the end of the document.

Accepted Manuscript

the absence of catalyst or base, gave no detectable conversion, demonstrating that the presence of both components is important in this protocol (Table 1, entries 11 and 12). [a] General conditions: in an argon-filled glovebox, a Schlenk tube was charged with rhenium catalyst, 1a (0.5 mmol), 2a (0.5 mmol), base and toluene (2 mL), in that order. The reaction was heated in an oil bath with argon stream. The yield of 3a was determined by 1 H NMR.

With our optimized conditions in hands, we then explored the substrates amenable for this transformation (Tables 2, 3 and4). First, with 2-aminobenzyl alcohol 1a, a series of secondary aromatic alcohols or ketones were engaged as coupling partners (Table 2). The reaction proceeded well for various substituted 1phenylethanol derivatives. (Table 2,123456789). 1-(naphthalen-2yl)ethanol (2b) gave full conversion and an excellent isolated yield (93%). Halide substituents, such as fluoro, chloro, bromo and even iodo groups at the para-position of the phenyl ring were well-tolerated (3c-3f, 75-92% isolated yields).

Table 2. Synthesis of quinolines via the annulation of 2-aminobenzyl alcohol with aromatic alcohols and ketones under the catalysis of rhenium complex C.

Accepted Manuscript

[a] General reaction conditions: 1a (0.5 mmol), 2 (0.5 mmol), catalyst C (1 mol%), toluene (2 mL), t-BuOK (10 mol%) at 150 o C with argon stream for 24 h; conversion determined by [START_REF] Joule | Heterocyclic Chemistry[END_REF] H NMR (based on substrate 2); isolated yield in parenthesis. [b] Acetophenone was used instead of 1-phenylethanol. [c] Yield of isolated product with 7% of starting material 2l. [d] 1.0 mmol of 1a was used.

Substrates bearing electron-donating and electronwithdrawing groups, such as p-methoxy-(2g), p-trifluoromethyl-1-phenylethanol (2h), were well tolerated, affording the products 3g and 3h in 79% and 85% isolated yields, respectively. It should be noted that starting from the ketone instead of the alcohol (Table 2, entry 1vs entry 2) slightly higher conversions and isolated yields were obtained (>98 vs 90% conversion), as the sole dehydrogenation of 1a is needed when starting from ketones.

1-Phenylpropanol (2i) and 1-tetralol (2j) gave corresponding 2,3-disubstituted quinolines 3i and 3j in good isolated yields (entries 10 and 11). Interestingly, heteroaromatic alcohols or ketones 2k-2n, based on pyridine, benzofuran and thiophene core, were smoothly converted into corresponding 2heteroaryl quinolines. 1,2 and 1,3-diketones, such 2o, 2p and 2q, gave di-quinolinyl (hetero)-arene products in quantitative yields, which could be further employed in coordination chemistry as polydentate ligands.

Then, aliphatic and cyclic alcohols were engaged in this acceptorless dehydrogenative coupling. Disappointingly, the coupling of cyclohexanol, used as model aliphatic secondary alcohol, did not proceed (4% yield, Table 3, entry 1), even if 1a was fully consumed yielding mostly 2-aminobenzaldehyde. It is likely that the dehydrogenative oxidation of aliphatic alcohol is more difficult than the one of 1-phenylethanol derivatives leading to relatively stable arylketone intermediates. Therefore, we continued to explore the scope with aliphatic ketones. Under our standard conditions, cyclic substrates and aliphatic ones 2r-2v gave all good isolated yields (up to 96%). Notably, cyclopropylethan-1-one 2u furnished 3u in good yield, which indicated that the reaction did not proceed via radical intermediates. The reaction of phenylacetaldehyde (2w) with 1a led to 3-phenylquinoline (3w) in moderate yield (63%). Finally, 2aminoacetophenone (1b) can be converted smoothly into 2phenyl-4-methylquinoline (3x) by coupling with 2a.

Table 3. Scope of the synthesis of quinoline derivatives with aliphatic ketones and aldehydes.

[a] General reaction conditions: catalyst C (1 mol%), 1 (0.5 mmol), 2 (0.5 mmol), toluene (2 mL), t-BuOK (10 mol%) at 150 o C with argon stream for 24 h; conversion determined by 1 H NMR; isolated yield in parenthesis. [b] Cyclohexanol was used instead of cyclohexanone and NMR yield is shown in parentheses. [c] Yield of isolated product with 8% of starting material 1a. [d] 1 mL of acetone was used. [e] 130 °C.

Interestingly, 2-phenylacetonitrile 4a has been recently proven to be an effective annulation partner in the synthesis of 2-alkylaminoquinolines. [28] To our delight, 4a could also be smoothly converted to 2-amino-3-phenylquinoline 5a with our catalytic system at 140 o C. The molecular structure of 5a (as well as 5b) were confirmed by X-Ray diffraction studies (Figure 1). As shown in Table 4, all the reactions proceeded smoothly and gave the desired products in moderate to good isolated yields. In particular, bromo-substituted 2-phenylacetonitriles 4b and 4c gave the corresponding products 5b and 5c, in 67% and 33% yield, respectively (Table 4, entries 2 and 3). Interestingly, halogen-containing products, such as 3e, 3l, 5b and 5c, can be further converted into more complex molecules via crosscoupling reactions. 2-(2-thiophenyl)acetonitrile 4d afforded the corresponding product in high yield (90%, entry 4) while, unexpectedly, parent 2-(3-thiophenyl)acetonitrile 4e led to Accepted Manuscript moderate conversion (42%) (Table 4, entries 4 and 5). Eventually, aliphatic butyronitrile 4f gave 2-amino-3ethylquinoline 5f in good yield (80%). Table 4. Scope of the synthesis of 2-amino-quinoline derivatives with nitriles.

[a] General reaction conditions: catalyst C (1 mol%), 1a (0.5 mmol), 4 (0.5 mmol), t-BuOK (10 mol%), toluene (2 mL) at 140 o C for 24 h; conversion determined by 1 H NMR (based on substrate 4); isolated yield in parenthesis. [b] 2.0 equiv. of 4f was used. In summary, a practical and sustainable synthesis of substituted quinolines was achieved via the annulation of 2aminobenzyl alcohol with a variety of secondary alcohols, ketones, aldehyde or nitriles. The reaction proceeds with a high atom efficiency via a sequence of dehydrogenation and condensation steps that give rise to selective C-C and C-N bond formations. The key to develop this first rhenium catalyzed acceptorless dehydrogenative coupling was the use of a welldefined complex bearing a tridentate diphosphinoamino ligand as the catalyst (1 mol%) in the presence of t-BuOK (10 mol%) at 150 °C.

Experimental Section Typical procedure for catalytic synthesis of quinolines

In an argon-filled glovebox, a 20 mL Schlenk tube was charged with the rhenium catalyst C (1 mol%), 1 (0.5 mmol), 2 (0.5 mmol), toluene (2 mL) and t-BuOK (10 mol%), in that order. The reaction was heated in an oil bath with argon stream at 150 o C for 24 h. After cooling to room temperature, the solution was diluted with ethyl acetate (2 mL) and filtered through a small pad of silica (2 cm in a Pasteur pipette). The silica was washed with ethyl acetate. The filtrate was evaporated and the crude residue was purified by column chromatography (SiO2, mixture of petroleum ether/ethyl acetate as eluent).

  , Dr. V. Dorcet, Prof. Dr. C. Darcel Univ Rennes, CNRS, ISCR -UMR 6226, F-35000, Rennes, France. [b] D. Wei, Prof. Dr. J.-B. Sortais LCC-CNRS, Université de Toulouse, CNRS, UPS, Toulouse, France E-mail: jean-baptiste.sortais@lcc-toulouse.fr [c] Prof. Dr. J.-B. Sortais Institut Universitaire de France, 1 rue Descartes, 75231 Paris Cedex 05, France.

Figure 1 .

 1 Figure 1. Perspective view of the products 5a (left) and 5b (right) (thermal ellipsoids drawn at the 50% probability level.

Table 1 .

 1 Optimization of the parameters of the reaction.[a]

	Entry Cat.(mol%)	Base (mol%)	Temp. (°C)	Yield (%)
	1	A (5)	t-BuOK (10)	140	88
	2	B (5)	t-BuOK (10)	140	87
	3	C (5)	t-BuOK (10)	140	90
	4	D (5)	t-BuOK (10)	140	7
	5	E (5)	t-BuOK (10)	140	5
	6	Re(CO)5Br (5)	t-BuOK (10)	140	0
	7	C (1)	t-BuOK (10)	150	87
	8	C (1)	KOH (10)	150	70
	9	C (1)	Cs2CO3 (10)	150	58
	10	C (1)	K2CO3 (10)	150	3
	11	C (1)	None	150	0
	12	No catalyst	t-BuOK (10)	150	3
	13	C (1)	t-BuOK (5)	150	74
	14	C (1)	t-BuOK (2)	150	50

Acknowledgements

We thank the Centre National de la Recherche Scientifique (CNRS), the Université de Rennes, the Université Paul Sabatier, and the Institut Universitaire de France (IUF).

COMMUNICATION

A sustainable rhenium catalyzed synthesis of substituted quinolines was achieved via the annulation of 2-aminobenzyl alcohol with various secondary alcohols, ketones, aldehyde or nitriles, under hydrogen borrowing conditions.

Duo Wei, Vincent Dorcet, Christophe Darcel and Jean-Baptiste Sortais *

Synthesis of quinolines via acceptorless dehydrogenative coupling catalyzed by rhenium PN(H)P complexes


Kévin Le Bon

Alan Schmitt

MLExplain

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

Introduction

The semantics of a programming language can be very complex. When a language has no specification, the semantics is then defined by the implementations of the language, i.e., interpreters and compilers. However even when a specification is available, it can be difficult to understand why the execution of a specific program results to a certain output.

The goal of the JSExplain project [START_REF] Charguéraud | JSExplain: A Double Debugger for JavaScript[END_REF] is to describe the execution of a JavaScript program by showing every step of an interpreter whose behavior is very close to the specification of JavaScript. In this paper, we show how we adapted JSExplain to OCaml.

Unlike JavaScript, OCaml has no official specification. However, OCaml code execution is fairly simple because the number of language constructions is small. We have written an interpreter for OCaml's typed abstract syntax tree (AST). This AST is still close to the source code yet it provides additional crucial information. For instance, it mentions resolved names, which is useful for module and signatures inclusion and mandatory for interpreting features like named parameters and optional parameters in functions. The semantic we give to OCaml is higher level than the one described in ZINC [START_REF] Leroy | The ZINC experiment: an economical implementation of the ML language[END_REF] virtual machine, i.e., an interpreter for bytecode after compilation.

JSExplain 2.1 A Double Debugger

We call a double debugger an interpreter that is able to run step by step and display the program's state and current location in source, as well as the state and location in the source of the interpreter itself. JSExplain is a double debugger for JavaScript. The aim of this tool is to help a user to better understand JavaScript's semantics, by providing an interpreter that is very close to the specification of JavaScript. JSExplain's interface highlights the expression of the program currently evaluated as well as the instruction of the interpreter that is executed.

Architecture

The core of JSExplain is a JavaScript interpreter written in a subset of OCaml. This interpreter is compiled to a subset of JavaScript and instrumented to generate a trace of its execution when run. This trace can then be navigated using a web-based tool. 1The subset of OCaml we support for writing the interpreter is purely functional with variables, constants, sequence, conditional, let-binding, function definition, function application (with support for prefix and infix functions), data constructors, records (including record projections, and the "record-with" construct to build a copy of a record with a number of fields updated), tuples (i.e., anonymous records), and simple pattern matching (only with non-nested patterns, restricted to data constructors, constants, variables, and wildcards). For convenience, let-bindings and functions may bind simple patterns (as opposed to only variables). We also support ppx extensions for monadic programming, to simplify the handling of errors.

The target language of our compiler is a purely functional subset of JavaScript where there is never any type conversion, where objects are used as records (no use of their prototype field), and where tuples are encoded into arrays.

We instrument the compilation to JavaScript by adding code that logs events, namely entering a function, creating a scope, assigning a variable, and exiting a function. Each event captures the state, the stack, and the values of all local variables in scope of the interpreter code at the point where the event gets triggered. Code that is traced is compiled with this instrumentation, whereas code that is not traced, for instance supporting libraries, is directly compiled to JavaScript.

When using the tool, the source JavaScript program is parsed and run through the instrumented interpreter, thus generating a trace. We can then navigate this trace to see the state of the interpreter as well as the state of the interpreted program. Recovering the information about the interpreted code is not completely straightforward. For example, to recover the fragment of code to highlight, we find in the trace the closest previous event that contains a call to function with an argument named term . This argument corresponds to the AST of a subexpression, and this AST is decorated (by the parser) with locations. Note that, for efficiency reasons, we associate to each event from the trace its corresponding term argument during a single pass, performed immediately after the trace is produced.

Similarly, we are able to recover the state and environment associated with the event. The state of the interpreted program consists of four fields: the strictness flag, the value of the this keyword, the lexical environment, and the variable environment. We implemented a custom display for these elements, and also for values of the languages, in particular for objects: one may click on an object to reveal its contents and recursively explore it.

Finally, a web interface is presented to the user, to navigate in the trace. This navigation can be forward and backward, and at all times the source code and interpreter code are highlighted, and their states are displayed. We also provide a way to specify breakpoints, using arbitrary JavaScript expressions, that reference both the interpreter and interpreted programs. One may thus reach a point where some interpreter line is being evaluated some source value satisfying a predicate, or vice-versa.

Note that JSExplain, and by extension MLExplain, runs a program to its completion to generate the trace, and it is that trace that is explored using the web interface. It thus does not currently offer the ability to alter the state of the program as it is being explored.

MLExplain

At first glance, JSExplain seems tightly linked to JavaScript. However, the architecture of the project is quite modular and can be used for a different programming language, by providing both an interpreter written in the subset of OCaml that we support and a way to display OCaml values.

Two compilers

To interpret OCaml code, we first need to parse and type it. However, our compiler does not allow us to use the standard library nor an external one, as they are not written in the subset of OCaml that we support. As we do not need to trace the parsing nor the typing, we have been able to separate totally the frontend from the interpreter itself and use another compiler to compile it. Figure 1 describes the architecture of the whole application.

The frontend is compiled with js of ocaml [START_REF] Vouillon | From bytecode to javascript: the js of ocaml compiler[END_REF], the compiler of the project Ocsigen [START_REF] Balat | Client-server Web applications with Ocsigen[END_REF]. The largest part of the frontend is a module that serializes the Typedtree -the typed AST of OCaml -into a JavaScript object compatible with the backend interpreter's own representation of the AST. We use the OCaml compiler, namely the compiler-libs library, to do the actual parsing and typing. We thus have the guarantee that the typed AST we get is the same as the official OCaml compiler AST.

Unfortunately, we cannot directly use the typed AST, as js of ocaml takes OCaml bytecode as input, which does not include sufficient information such as the names of constructors. After parsing and typing, we thus navigate the AST and call JavaScript functions that create the data in the expected format.

Compiler limitations

As stated before, the backend of our interpreter is written in a purely functional strict subset of OCaml. As a consequence, it was necessary to encode some features, such as exceptions. To this end, we use a monadic approach and rely on ppx extensions to simplify the syntax.

As an example, consider the option monad, whose main operator is defined as follows.

let bind_option opt f = match opt with | Some value -> f value | None -> None

To use this operator, one would need to write the following.

bind_option (function_that_could_fail 0) (fun a -> continuation a)

Such code can become difficult to read, especially when one is chaining several functions. The use of ppx lets us write much simpler code, which is transformed to the previous version during parsing. let%some a = function_that_could_fail 0 in continuation a

Web interface changes

The data structures manipulated by MLExplain are very different from those manipulated by JSExplain since they don't interpret the same language. We thus had to modify the web interface so that it can recognize the different syntactic elements of OCaml and pretty print them correctly as well as OCaml values.

Fortunately the web interface is very simple. It is composed of some auxiliary JavaScript files, the main JavaScript filenavig-driver.js -containing the logic of the application and the corresponding HTML page. The only modified file is navig-driver.js. The resulting tool can be tested online2 and is shown in Figure 2. The top-left panel shows the interpreted program, here a simple eval function using GADTs, with the state of the program depicted on the right. The bottom panel shows the interpreter, with its state below. One can see that at this point the eval identifier is being evaluated, with the values of r, l, and b shown on the right.

Design Choices

We now motivate our design choices. First, we use JavaScript because MLExplain is a witness that JSExplain can easily be adapted to other languages, by providing three components: an interpreter written in the subset of OCaml that our compiler supports, a parser of the language, and a library to display runtime values. It would be possible to sever all links to the infrastructure provided by JSExplain, but this would require significant work. Second, it is possible to use an existing debugger to explore how an interpreter works. This is how we initially debugged our JavaScript interpreter and this was the motivation to start working on JSExplain. Indeed, our interpreter is written as a purely functional set of recursive functions that extensively use monadic operations implemented in continuation passing style. It is difficult to correctly navigate such functions, as stepping over a continuation means reaching the end of the program. One thus has to be aware of whether a function call involves a continuation or a usual function. In addition, we did not find an easy way to display the state of the interpreted program, even when relying on the use of fixed names for the term, the state, and the context. The use of fixed names may seem fragile, but as we only rely on a few of them and as the signature of the evaluation functions are uniform, we have not observed any issue with this approach.

Statistics

We give some statistics about the project in Figure 3. As can be seen, the largest part of the code is the frontend, in particular the conversion from OCaml's AST to our format. The interpreter is quite short, because the execution of OCaml is actually very simple. Note that we support all of OCaml, with the exception of objects and record patterns, which we have not had the time to implement.

Conclusion

We have shown how JSExplain can be easily adapted to other programming language, in this case OCaml. Most of the complexity of OCaml being its typing, writing the interpreter was quite straightforward. The current implementation of our interpreter is very simple and contains a lot of documentation. The architec-ture of the code is as unsurprising as possible, enabling easy extensions. As the design of our interpreter is very simple, it could be considered as a first step towards a specification of OCaml. MLExplain also provides a comfortable environment to experiment with the semantics of OCaml. It is thus a good playground for future evolution of the language.

As future work, we plan to extend the subset of OCaml supported by our compiler, to be able to directly use the standard library when writing interpreters. We also plan to implement the few OCaml constructs missing from our interpreter. In addition, it would be most useful to document the evaluation order of every OCaml construction to make sure our interpreters follows it. Finally, we want to improve the web interface and to allow the user to load code from multiple files.

Figure 1 :

 1 Figure 1: Architecture of MLExplain

Figure 3 :

 3 Figure 3: Statistics about the project's code

https://jscert.github.io/jsexplain/branch/master/ driver.html

https://docteur-lalla.github.io/mlexplain/branch/ master/driver.html


est destinée au dépôt

Investigation of PEKK crystal morphology and modelling of the crystallization kinetic of PEKK composites

Investigation of crystal morphology and modelling of PEKK (Poly-Ether-Ketone-Ketone) crystallization kinetic

Saber Chelaghma Pour les polymères thermoplastiques renforcés de fibres de carbone, le taux de cristallinité et la morphologie induite lors de la cristallisation ont un impact certain sur leurs propriétés physiques et mécaniques. Ces deux paramètres sont non seulement dépendants des conditions de mise oeuvre mais aussi des constituants du composite. Afin d'améliorer le contrôle et l'optimisation des cycles de fabrication de ces matériaux, il est nécessaire de construire une modélisation avancée de la cristallisation. Dans la littérature, de nombreux modèles ont été proposés afin de décrire la cinétique de cristallisation des polymères semi-cristallins [START_REF] Avrami | Granulation, Phase Change, and Microstructure Kinetics of Phase Change. III[END_REF][START_REF] Nakamura | Some aspects of nonisothermal crystallization of polymers. Relationship between crystallization temperature, crystallinity, and cooling conditions[END_REF][START_REF] Ozawa | Kinetics of non-isothermal crystallization[END_REF]. Ces modèles s'avèrent peu adaptés pour décrire la cristallisation dans le cas d'un polymère de la famille des PAEK. En effet, comme pour le PEEK, le PEKK se distingue par une cristallisation particulière qui fait intervenir deux mécanismes. Une cristallisation primaire qui correspond aux étapes de germination-croissance décrites dans la théorie de Lauritzen et Hoffmann [START_REF] Hoffman | Crystallization of Bulk Polymers with Chain Folding : Theory of Growth of Lamellar Spherulites[END_REF], suivi d'une cristallisation secondaire correspondant à une cristallisation interlamellaire ou à un perfectionnement des cristaux déjà présents. Des modèles ont été spécifiquement développés pour décrire les phénomènes de cristallisation particuliers du PEEK [START_REF] Velisaris | Crystallization kinetics of polyetheretherketone (PEEK) matrices[END_REF]6]. Cette étude vise dans un premier temps à développer un modèle de cinétique adapté au PEKK, en se basant sur les étapes de germination-croissance pour le mécanisme 1 et sur une identification des paramètres à travers une loi d'Avrami (mécanisme 2). Nous pourrons ainsi mettre en évidence l'influence de différents paramètres, tels que la température du palier isotherme, la vitesse de refroidissement. Le développement de ce modèle s'appuie sur une étude expérimentale divisée en trois étapes. Tout d'abord des mesures calorimétriques à l'aide d'une DSC 8000 de Perkin Elmer permettant de quantifier les échanges thermiques lors de la cristallisation. Différents paliers isothermes entre 250 et 300°C ont été réalisés ainsi que six vitesses de refroidissement comprises entre 1 et 100°C/min. L'évolution du taux de cristallinité relative est tracée en fonction du temps de cristallisation sur la Fig. 1-a. Le temps de cristallisation dépend de la température du palier isotherme. En effet, plus la température du palier est haute, plus le temps de cristallisation sera long. Le PEKK cristallise au bout de 35 min à 315°C alors que le PEEK cristallise en moins de 6 min pour les paliers isothermes les plus hauts [6]. Le temps de cristallisation du PEKK chute à 2 min pour une cristallisation à 270°C. De plus, contrairement au PEEK qui cristallise toujours à au moins 20% [6] malgré des vitesses de refroidissement élevées (150°C/min), le PEKK est quasi amorphe lorsqu'il est refroidit au-delà de 50°C/min.

Fig. 1. a) Cinétique de cristallisation du PEKK pour des paliers isothermes b) Croissance sphérolitques observée sous microscope optique munie d'une platine Linkam

La deuxième étape est réalisée par analyse thermo-microscopique à l'aide d'une platine chauffante permettant l'observation directe des structures cristallines (sphérolites). La platine Linkam THMS 600 PS permet de caractériser la vitesse de croissance des sphérolites ainsi que le taux de germination (Fig. 1-b) en imposant différents cycles représentatifs des procédés de fabrication. Les données cinétiques relevées par l'observation de la croissance sphérolitiques et l'apparition de germes seront injectées dans le modèle cinétique. Les différences observées entre les données obtenues à l'aide de la platine (correspondants aux étapes de germination-croissance) et les données DSC pourront être attribuées à la cristallisation secondaire. Nous avons pu mettre en évidence avec le modèle développé l'évolution du taux de germination et de la vitesse de croissance des cristallites en fonction des températures de palier et des vitesses de refroidissement.

Fig. 2. Transcristallinité observée sous microscope optique munie d'une platine Linkam

Dans un second temps l'influence de fibres ou de charges conductrices sur la cinétique de cristallisation est analysée. En effet, la formation d'une phase transcristalline a été observée en présence de fibres de carbone (Fig. 2). Le changement de morphologie implique un changement de cinétique à travers une modification du taux de germination. L'ajout de fibres à tendance à accélérer la cristallisation du PEKK en jouant le rôle de surface de germination préférentielle. Au travers de cette démarche structurée, nous avons développé un modèle de cinétique pour prédire les temps de cristallisation en fonction des paramètres de mise en oeuvre en prenant en compte la présence de fibres et charges conductrices. L'ensemble de ces résultats nous a permis d'améliorer notre compréhension des mécanismes de cristallisation particuliers du PEKK. L'étape suivante consiste à identifier les paramètres de la microstructure qui vont grandement influencer le comportement mécanique du matériau. L'objectif à terme est de pouvoir définir une fenêtre process afin d'obtenir les propriétés mécaniques optimales lors de la mise en forme des matériaux.

  Chelaghma, Olivier de Almeida, Jean-Noël Périé, Philippe Marguerès, Bénédicte Reine, Alain Vinet, Jean-Charles Passieux To cite this version: Saber Chelaghma, Olivier de Almeida, Jean-Noël Périé, Philippe Marguerès, Bénédicte Reine, et al.. Investigation of PEKK crystal morphology and modelling of the crystallization kinetic of PEKK composites. JNC 20 -Journées Nationales sur les Composites, Jun 2017, Champs-sur-Marne, France. p.859-868. hal-01686602 Etude de la morphologie cristalline et modélisation de la cinétique du PEKK (Poly-Ether-Cétone-Cétone)

1, 2 , Olivier De Almeida 2 , Jean-Noel Périé 2 , Philippe Marguerès 2 , Bénédicte Reine 1 , Alain Vinet 3 , Jean-Charles Passieux 2

	1 : Institut de Recherche Technologique Saint-Exupéry
	118, route de Narbonne -CS 44248, F-31432 Toulouse Cedex 4
	e-mail : saber.chelaghma@irt-saintexupery.com
	2 : Institut Clément Ader
	Université de Toulouse, UPS/INSA/ISAE/Mines Albi, ICA UMR CNRS 5312,
	3 rue Caroline Aigle, 31400 Toulouse, France
	3 : Airbus Group Innovations
	18 rue Marius Terce, BP 13050, 31300 Toulouse

Remerciements

Ces résultats ont été obtenus dans le cadre du projet de recherche « COMPINNOVTP ». Nous tenons à remercier les membres industriels et académiques de l'IRT Saint Exupéry qui ont soutenu ce projet : AGI, Airbus Opération, Airbus Helicopters, Airbus Defence & Space, Thales Alenia Space, ICA, CIRIMAT, ISAE, IMRCP. Nous remercions également le Commissariat Général aux Investissements et l'Agence Nationale de la Recherche pour leur soutien financier dans le cadre du Programme d'Investissement d'Avenir (PIA).


Guix-HPC is a collaborative effort to bring reproducible software deployment to scientific workflows and high-performance computing (HPC). Guix-HPC builds upon the GNU Guix 1 software deployment tool and aims to make it a better tool for HPC practitioners and scientists concerned with reproducible research.

Guix-HPC was launched in September 2017 as a joint software development project involving three research institutes: Inria 2 , the Max Delbrück Center for Molecular Medicine (MDC) 3 , and the Utrecht BioinformaticsCenter (UBC) 4 . GNU Guix for HPC and reproducible science has received contributions from additional individuals and organizations,including Cray, Inc. 5 and Tourbillion Technology 6 . This report highlights key achievements of Guix-HPC between its launch date in September 2017 and today, February 2019.

4.

Outline

Guix-HPC started up with the following high-level objectives for the 2017-2018 period: • Reproducible scientific workflows. Improve the GNU Guix tool set to better support reproducible scientific workflows and to simplify sharing and publication of software environments.

•

Cluster usage. Streamlining Guix deployment on HPC clusters, and providing interoperability with clusters not running Guix.

•

Outreach & user support. Reaching out to the HPC and scientific research communities and organizing training sessions.

The following sections detail work that has been carried out in each of these areas.

Reproducible Scientific Workflows

Research heavily depends on computational results, which in turn depends on the ability to reproduce software environments. As key scientific organizations such as the Association for Computer Machinery (ACM) and theNaturescientificjournalsbegin requiring authorstopublish codealongside their scientific articles, reproducing software environments remains difficult.

GNU Guix offers a way to address these issues that does not suffer from the opacity and lack of reproducibility of "container-based"solutionssuch as Docker or Singularity.

Software Environment Version Control

In June 2018, we developed tools to aid users who wish to have tight control over their software environments. The guix pull command can now be used to deploy a specific revision of Guix, and guix describe provides information about the currently used revision. Along with the new channels facility, which allows users to obtain software packages from third-party repositories, this offers a transparent way to replicate a Guix setup, as explained in the release notes of version 0.16.07 . Better yet, Guix allows mixing software packages coming from different Guix revisions through a new mechanism called inferiors.

With thehelpof theSoftwareHeritage 8 engineers,wedesigned and implemented a back-end that allows Guix to fetch source code from Software Heritage 9 . Software Heritage is a persistent source code archive that preserves complete source code repository histories. This functionality thus allows Guix to retrieve source code even if the original source code reposi-6.

tory vanished or got corrupted-an obviousrequirement to reproducesoftware environments. To our knowledge this makes Guix the first software deployment tool backed by a persistent and reliable source code archive.

GNU Guix is involved in the Reproducible Builds 10 effort. In 2018 we were again present at the Summit, along with a dozen of other projects concerned with software deployment. Together we worked to further reproducible builds and take advantage of them 11 . This is ground work that, we believe, is key to enabling reproducible scientific workflows.

Reproducible Pipelines

Jupyter Notebooks 12 have become a tool of choice for scientistswilling to share, and hopefully reproduce computational experiments. Yet, nothing in a notebook specifies which software packages it relies on, which puts reproducibility at risk. For example,a notebook might rely on Python 3and a specific version of NumPy and Scipy; if someone receives the notebook and tries to execute it with, say, Python 2 and another version of NumPy and SciPy, the result may well be different,or execution might fail altogether. To address this, during a 4-month internship at Inria, Pierre-Antoine Rouby implemented a prototype Guix "kernel" for Jupyter 13 . In a nutshell, the kernel allows notebook writers to precisely specify the software environment the notebook depends on: the Guix packages, and the Guix commit. This ensures that someone replaying the notebook will run it in the right environment as the author intended.

For less interactive computationsthat are to be evaluated on HPC clusters, scientists often compose applications to build so-called pipelines that express common data processing workflows. In state of the art workflow systems, it is often the users' responsibility to prepare a suitable environment in which the workflow'sassumptionsabout softwareapplicationsand libraries are satisfied. Some workflow systems allow the authors to declare a processtobedependenton softwareprovided in a Docker applicationbundle, which is convenient but ignores the problem of software provenance.

As demonstrated by Pjotr Prins in a blog post 14 , GNU Guix can be used to build reproducible software environmentsincrementally or declaratively to prepare the context in which an existing Common Workflow Language (CWL) workflow is to be executed. Compared to the use of Docker containers this unlocks software provenance and source/binary transparency while only requiring minor modifications to existing workflow definitions. While the burden of preparing the environment still lies with the user, this approach allows for a smooth transition to more reproducible workflows asGuix environmentscan betransparently described with a plain text manifest.

The genomics pipelines presented in the paper PiGx: Reproducible Genomics Analysis Pipelines with GNU Guix 15 are an example for an attempt to movetheresponsibilityof provisioningtherequired softwareenvironment from the pipeline user to the package manager. By using Guix at build time the PiGx pipelines are able to benefit from reproducibile software environments and pass that benefit down to the users at runtime. The Guix Workflow Language (GWL) 16 takes a different approach: instead of assuming that a suitable software environment is provided-by the user, by black box container images, or through a build system-it extends Guix itself with a workflow definition language that can make use of its rich facilities for reproducible software deployment. In the past year the GWL has gained support for a Python-like whitespace-aware workflow definitions through Wisp 17 , syntax for embedding foreign language code snippets in processes, and facilities to more conveniently specify or detect data dependencies between processes. The GWL and the Guix Jupyter kernel take the same approach: making reproducible software deployment a built-in feature of a larger tool. While there are other beneficial ways to integrate Guix into existing tools, as demonstrated by work on PiGx, we believe tight integration of software deployment and "workflow execution" is a novel and powerful approach that we will keep exploring.

Packaging

Since the Guix-HPC effort was started in September 2017, around 3,000 packages were added to Guix itself; of these many had to do with linear algebra,computationalfluid dynamics,bioinformatics,and statistics,as reported in the HPC release notes on the Guix-HPC blog 18 .

In addition, our institutes have developed their own package collections, sometimes as a staging area before packages are reviewed and integrated in Guix proper: These package collections, along with the curated package set that comes with Guix (more than 9,000 packages), cover a wide range of HPC use cases.

One such case is numerical simulation. Development work in this area has been supported by Tourbillion Technology 30 . Within Guix a module named (gnu packages simulation) has been established to contain package definitions for simulation software. In 2018 the FEniCS 31 finite element framework was added to the module, complementing the OpenFOAM 32 finite volume framework that was added in 2017. Together these packages allow engineers and scientists to tackle a broad range of challenging problems within industry and academia. The ability of Guix to reproduce softwareenvironmentson differentsystemsissignificantlyhelpful in theworkflow associated with this type of project. In these projects the initial stages of model development are often undertaken on relatively small computer systems, scaling-up to HPC systems for the full computations when the models are ready. This move can sometimes be problematic, especially for models with complex dependencies on underlying libraries. By setting up consistent environments Guix ensures that even highly-complex models can be confidently transfered.

10.

Guix added support in its 0.13.0 release of mid-2017 for ARM's 64-bit aarch64 processors, which are becoming increasingly popular as a target for HPC clusters. Since then, several core linear algebra and maths libraries have had work done, thanks to Cray Inc 33 , to better support this architecture.

Cluster Usage

GNU Guix has been deployed on clusters at our research institutes and in other places. One of our first task has been to simplify the deployment and installation of Guix on clusters, providing new features for distributed setups to its build daemon and command-line tools, and documenting the installationprocessforsystemadministrators 34 .Thisistheoptionwerecommend because it gives cluster users a lot of flexibility: each user can install, upgrade, and remove packagesat will, create software environmentson the fly with guix environment, and so on.

However, scientists may also need to target clusters where Guix is not installed, and we wanted to offer interoperability with those. As so-called "container-based solutions" like Docker and Singularity are being deployed on clusters, we developed guix pack, a tool that can create "container images" 35 . In this setup, users use guix pack on their laptop to generate an image that contains precisely the software environment they need, and then send it over to the cluster to run their application. guix pack can generate imagesusable by both Singularity and Docker; it can also generatetarballs containing relocatable executables 36 . This interoperability tool allows userstonot giveupon thereproducibility,transparency,and flexibilitybenefits offered by Guix.

To help cluster users get started with Guix, hpcguix-web 37 , initially developed at the UMC Utrecht, provides a web interface that allows users to search for software packages and to learn how to install them. A public instance is visible on the Guix-HPC web site 38

  33http://www.cray.com/ 11.

  . Hpcguix-web is customizable 34 https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/ 35 https://guix-hpc.bordeaux.inria.fr/blog/2017/10/using-guix-without-being-root/ 36 https://www.gnu.org/software/guix/blog/2018/tarballs-the-ultimate-container-image-format/ 37 https://github.com/UMCUGenetics/hpcguix-web 38 https://guix-hpc.bordeaux.inria.fr/browse 12. and theinstancerunning in Utrechtprovidesuserswith additionalinformation such as how to use the batch scheduler.

https://ubc.uu.nl/

https://www.cray.com

http://tourbillion-technology.com/

https://guix-hpc.bordeaux.inria.fr/blog/2018/12/hpc-reproducible-research-in-guix-0-16-0/

https://www.softwareheritage.org

https://issues.guix.info/issue/33432

https://rescience.github.io

https://guix-hpc.bordeaux.inria.fr/about

Outreach and User Support

One aspect of our work on Guix-HPC is to "spread the word" about the importance of being able not just to replicate software environments, but also to inspect and modified those software environments. These are key to proper scientific understanding and experimentation. This section summarizes articles we published and talks we gave around these topics.

Articles

Since the inception of Guix-HPC, two scientific articles were published in peer-reviewed conferences: and compares existing tools to achieve software environment reproducibility: application bundles (also referred to as "containers"), CONDA, and Guix.

We have published 12 articles on this blog 45 touching a range of technical topics: running Guix without being root, on the performance of pre-built binaries, creating reproducible workflows with CWL or PiGx, and more.

In September 2017, Inria, the MDC, and the Utrecht Bioinformatics Center published an article 46 for the project launch. On-line magazine HPC Wire covered it 47 .

Talks

Since Guix-HPC was started, we gave talks at a number of venues:

Perspectives

In the coming years, we plan to continue our development efforts. Some of them concern directly the core of Guix. In particular, we would like to further simplify the use of Guix on clusters where Guix is not installed by refining the guix pack tool or by turning the build daemon into a library that would make it easy to run builds as non-root on such systems. We may also provide services built around that; guix pack as a service, for instance, would make it easy for users to build "container images" in a reproducible fashion.

Of the more exciting developments, work on the GWL and on the Jupyter kernel shows that integrating reproducible software deployment capabilitieswith existing applications is a fruitful endeavor. We believe it's an easy way to bring reproducible deployment into the hands of scientists, directly within the tools that they use daily. We will continue working in that direction, and we hope to extend to other tools as well-workflow management tools, batch schedulers, and "active paper" authoring tools come to mind.

Beyond development, one of the missions of Guix-HPC is to support reproducible science efforts. Achieving fully reproducible scientific computing pipelines is a lot of work in itself, but we believe reproducible software deployment is a prerequisite. We will continue publishing on this topic, giving talks and training sessions, and generally raise awareness of the importance of reproducible software deployment, the ways Guix helps achieve that, and the shortcomings of popular approaches such as Dockerstyle application bundles. We hope to work more closely with initiatives such as ReScience 59 and with scientific societies to investigate ways Guix could help improve their reviewing workflows.

We are very much open to new ideas and we'd like to hear from you 60 !

Credits

Illustrations are copyright © 2019 Ricardo Wurmus, available under the terms of the CC-BY-SA 4.0 international licence.

19.