Katsuro Inoue
email: inoue@ist.osaka-u.ac.jp

Yuya Miyamoto

Daniel M German

Takashi Ishio
email: ishio@is.naist.jp

Finding Code-Clone Snippets in Large Source-Code Collection by ccgrep

Keywords: Code Snippet Search, Pattern Matching, Clone Types

Finding the same or similar code snippets in the source code for a query code snippet is one of the fundamental activities in software maintenance. Code clone detectors detect the same or similar code snippets, but they report all of the code clone pairs in the target, which are generally excessive to the users. In this paper, we propose ccgrep, a token-based pattern matching tool with the notion of code clone pairs. The user simply inputs a code snippet as a query and specifies the target source code, and gets the matched code snippets as the result. The query and the result snippets form clone pairs. The use of special tokens (named meta-tokens) in the query allows the user to have precise control over the matching. It works for the source code in C, C++, Java, and Python on Windows or Unix with practical scalability and performance. The evaluation results show that ccgrep is effective in finding intended code snippets in large Open Source Software.

Introduction

Finding and locating the same or similar code snippets in source code files is a fundamental activity in software development and maintenance, and various kinds of software engineering tools or IDEs have been proposed and implemented [START_REF] Roehm | How do professional developers comprehend software?[END_REF].

A (code) clone is a code snippet that has an identical or similar snippet, and a pair of such snippets is called a (code) clone pair [START_REF] Carter | Clone detection in telecommunications software systems: A neural net approach[END_REF]. A large body of scientific literature on clone detection has been published and various kinds of code clone detection tools (detectors) have been developed [START_REF] Rattan | Software clone detection: A systematic review[END_REF][START_REF] Roy | Comparison and evaluation of code clone detection techniques and tools: A qualitative approach[END_REF]. These code clone detectors are candidates for finding similar code snippets, but most of those are designed to detect all of the code clone pairs in the target, which are generally excessive to the user who wants to search for a specific query snippet.

It has been reported that grep [START_REF]Gnu grep 3.3 manual[END_REF], a character-based pattern matching tool, is widely used in the software engineering practice to find lines with a specific keyword [START_REF] Kernighan | The Practice of Programming[END_REF][START_REF] Singer | Whatś so great about 'grep' ? implications for program comprehension tools[END_REF], although making a query for a code snippet that spans multiple lines needs some skill and effort.

In this paper we propose a tool, named ccgrep (code clone grep), to find code snippets by using the notion of clone detection and pattern matching. Search queries can be simply code snippets, or code snippets enhanced with meta-tokens having a leading $ that can provide flexibility to narrow or broaden the search query. ccgrep is not an ordinary code clone detector that finds all code clone pairs in the target program and is a code snippet finder that reports code snippets composing code clone pairs against the query snippet.

ccgrep works on Windows or Unix as a simple but reliable clone detector and pattern matching tool for C, C++, Java, and Python. ccgrep has been applied to various applications, and it showed high scalability and performance for large source-code collection. ccgrep is an Open Source Software system and can be obtained from GitHub4 .

Motivating Example

Some uses of the ternary operator (e.g., exp1 ? exp2 : exp3 meaning the result of this entire expression is exp2 if exp1 is true, otherwise the result is exp3available in C, C++ and Java) are considered bad practice [START_REF] Soetens | Studying the effect of refactorings: A complexity metrics perspective[END_REF]. For example, the use of a < b ? a : b is arguably harder to read than using min(a,b). Therefore, it might be desirable to replace the ternary operator with a function or macro that returns the minimum value. The following is an example found in the file drivers/usb/misc/adutux.c in the Linux kernel (v5.2.0). amount = bytes to read < data in secondary ? bytes to read : data in secondary;

This line of code should be replaced with a more readable expression (note that the macro min in Linux guarantees no side effects): amount = min(bytes to read, data in secondary);

We might consider that finding all occurrences of such usage of the ternary operator could be done by clone detectors. A popular clone detector NiCad [START_REF] Cordy | The nicad clone detector[END_REF] reports 646 block-level clone classes for the drivers/usb files by the default setting, but no snippet with the ternary operator case is included in the result because it is too small to be detectable.

Alternatively, we would try it with grep but it is not easy. For example, simply executing "grep '<'" for all 598 files (total 51,6394 lines in C) under /drivers/usb produces 16335 matching, including many undesired patterns such as "if (a<b)", "for (i=0; i<x; ...)", or "#include <linux/...>". We could narrow the matches by concatenating grep like, grep '<' -r . | grep '?' | grep ':' However, it still produces 149 matches. Perhaps more problematic is that the expressions could span multiple lines. While it is possible to create a complex regular expression to find these expressions, it would be time-consuming and potentially error-prone.

Ideally, we would like to be able to specify a simple and easy-to-create-andunderstand query to find these types of snippets. Therefore in this paper, we propose ccgrep and its query is written simply as:

a < b ? a : b
In a nutshell, this query specifies that a variable (represented by a) should be followed by < and then the second variable (represented by b), followed by a ?, followed by the same first variable found, followed by :, followed by the second variable. Also, white spaces and comments should be ignored. This query would match all type 2 clones (mentioned in Sec.3.3) with consistent variable names such as x<y?x:y but it would not match x<y?x:z.

As a practical application, we have used this query to identify 3 instances of such an expression in Linux's drivers/usb and submitted patches to replace them with min. Two of those patches have been accepted already into Linux.

3 Overview of Code Clone Query by ccgrep

Basic Features

The input of ccgrep is the query and the target of the source code files in the same programming language. The output is a list of the matched code snippets in the target. The query and the matched code snippets form clone pairs. The query is a code snippet of single or multiple lines and is composed of the regular tokens in the language and the extended tokes with meta symbols having a leading $. We will describe these based on the classification of the clone types. Formalization of the matching is presented in Appendix and also in [START_REF] Inoue | Code clone matching: A practical and effective approach to find code snippets[END_REF].

Query for Type 1 Clone

A Type 1 code clone pair is two code snippets possibly with different spacing, line break, or comment. To find type 1 cloned snippets, a code snippet in the programming language is directly given as the query, with a leading $ for each identifier or literal. Note that in the following examples, we will use Java as the programming language.

Query: int $a= $0; Target: int a=0 /* some comments */; Match Target: int b=0 ;

Not Match

In this case, the query matches a code snippet with a comment, but it does not match the latter case of identifier b. The users do not worry about the white spaces and comments in the query.

Query for Type 2 Clone

A Type 2 code clone pair is two code snippets with the difference of the replacement of identifiers and literals, in addition to the difference of type 1 clones. In type 2 matching, a user-defined identifier in the query matches any identifier in the target. The same also applies to literal. This "normalization" of the user-defined names allows very flexible pattern matching to find different identifiers or literals. By default, ccgrep executes so-called Parameterized match [START_REF] Baker | A program for identifying duplicated code[END_REF] or P-match for short, such that if two identifiers (or literals) in the query are the same, then the corresponding tokens in the target must be consistently the same. These normalization and p-match are formally explained in Appendix.

Query: a = 0; a = a + b; Target: y = 0; y = y + c; Match

Target: y = 0; y = z + c; Not Match
In the former case, a consistently corresponds to y, but in the latter case, it does not5 .

Query for Type 3 Clone

A Type 3 code clone pair is two code snippets with a difference of some statements of addition, deletion, or change, in addition to the distinction of type 2.

We employ wild-card tokens in the query, which extend the matching from the original seed tokens. The seed snippet and the matched snippet form a code clone pair of type 3. We can replace a token in the seed snippet with '$.' that matches any single token.

Seed: a = 5 ; Query: a = $. ; Target: a = b ; Match '$$' is a wild-card token to match zero or more tokens before the next token matches.

Seed: a = 10 ; Query: a = $$ ; Target: a = b+c+10 ; Match

Target: a = f(g,h) ; Match
The following is a more complex example.

Seed: a= f(q); if(a<0){a=-a;}

Query: a= $f(p); $$ if(a<0){a=-a;} Target: b= f(q); if(b<0){b=-b;} Match
Target: b= f(q); c= c+10; d=20; if(b<0){b=-b;} Match

Finding Various Code Snippets

Combining the regular tokens and meta-tokens in the query, we can find many different kinds of code patterns in the target, from simple to complex ones.

Method XY Z with no parameter Query: $XYZ( )

Method XY Z with 0 or more parameters Query: $XYZ($$)

Method print with variable buf as the 1st parameter Query: $print($buf, $$)

Any method definition Query: T f($$){$$} Note that type names are treated as identifiers and then T matches any type name.

Getter method Query: T f(){return this.v;} Setter method Query: T1 f(T2 v1){this.v1=v2;} if statement Query: if ($$){$$} f or statement using control variable Query: for(T i=0; i<$$; i++){$$}

In addition to finding these patterns, one of the usable use-cases would be a copy-and-paste code search. A developer finds a bug in a system and locates the snippet that causes the defects. She would want to find the same or similar occurrences of the bug in the system, then she copies the buggy snippet and runs ccgrep with the pasted snippet as the query. Then she instantly gets type 2 clone snippets. She does not need to set up a heavy clone detector, nor does she need to do tedious analysis of the unnecessary detection results.

Architecture of ccgrep

The architecture of ccgrep is presented in Figure 1. Tokenizer Generators: Parser generator ANTLR is used to generate two kinds of tokenizers. For the target tokenization, only the language definition is used to recognize the regular tokens, but for the query tokenization, the definition of the meta-tokens and that of regular tokens are used. This process has been executed only once for each target language. Tokenizers: Each tokenizer removes white spaces and comments from the input files and decomposes the code into tokens. The query tokenizer accepts the meta-tokens starting with $ and the regular tokens defined by the language, but the target tokenizer accepts only the regular tokens. The tokenizer for the target files is executed in parallel for each file, along with the following CC Matcher. CC Matcher: This performs a naive sequential pattern matching algorithm between two token sequences for the query (of the length m) and the target (of the length n), whose worst-case time complexity is O(mn) [START_REF] Gusfield | Algorithms on Strings, Trees and Sequences[END_REF]. For type 2 code clone matching, we record the position for each identifier and literal in Map Table to check proper P-matching. The table contents are flushed for each query. Option controls the normalization level, input language, output form, and many others. Output Formatter: This process constructs the output for the successful matching result. Based on the input option, we can view the match result, like grep, in the form of the file name associated with the matched top line as the default, or as many other styles such as full matched lines, only the number of lines, or so on.

ccgrep is written in Java associated with the ANTLR output, and it is very easily installed and executed on various Unix or Windows environments with a single JAR file (about 1M byte) containing all necessary libraries.

Evaluation

The goal of the evaluation is to show that our proposed approach can find various kinds of intended code snippets effectively and efficiently. This goal could be decomposed into the following three research questions. the token-based naive sequential pattern matching approach fast enough in practice?

RQ1: Query Expressiveness

As shown in previous sections, it is obvious that our approach can easily create various query patterns for type 1 matching, type 2 matching with P-match, and type 2 matching with non-P-match, by specifying a code snippet associated with appropriate options. In addition, we can specify the name of an identifier or literal, if we place $ before the name.

A type 3 code-clone snippet is one with a few statement addition, or deletion, or change for a seed snippet. Thus the query for type 3 matching could be made from the seed by adding meta-tokens such as $., $$, or $*, deleting some regular tokens in the seed, or modifying some regular tokens with $., $$, or other metatokens.

Therefore, the queries for type 1 to 3 code clones can be effectively created from a code snippet at hand.

RQ2: Accuracy of ccgrep

For evaluation of query-matching (or information retrieval) systems, recall and precision values, computed by comparing the matched results with the oracles for the queries, are popularly employed [START_REF] Baeza-Yates | Modern Information Retrieval[END_REF]. Here in our approach, however, the query to CC matching has no ambiguity and it reports the matching result rigorously as expected and specified by the query with options. In such a sense, the result is always the same as the oracle, i.e., the recall and precision are always 1. Thus, instead of using recall and precision, here we simply investigate if ccgrep works accurately in the sense that code clones already reported by other approaches could be found by our approach.

For this purpose, first, we have employed BigCloneBench [START_REF] Svajlenko | Evaluating clone detection tools with bigclonebench[END_REF] which is a huge collection of various kinds of code clones. We have extracted all pairs classified as type 1 and type 2 code clones from BigCloneBench, and for each clone pair (sp1, sp2), we have checked if sp2 is successfully found in the result of ccgrep for sp1 as a query with appropriate options, and vice versa. Table 1 shows the numbers of type 1 and 2 clones found by ccgrep. As we can see in Table 1, most type 1 and 2 clones are found accurately. There were several cases of not-found clones, and we have investigated further those cases and recognized that those cases are faults of the classification of BigCloneBench, some of which should be classified into type 3, and some others are not clones. Thus, we can say that all of the proper type 1 and 2 clones in BigCloneBench were perfectly found by ccgrep.

For type 3 clones, since BigCloneBench contains huge type 3 data and we cannot make the queries for those, we have instead used CBCD data [START_REF] Li | Cbcd: Cloned buggy code detector[END_REF], that contains 11 type-3 clone sets taken from the source code of Git, the Linux kernel, and PostgreSQL. We have crafted type 3 queries from one of the code snippets in each clone set as the seed and have checked if those queries accurately match the other snippets in the same clone set. We have confirmed that all the crafted queries accurately match other snippets in each clone set.

As far as our investigation, all the matches are controlled by the query and are performed accurately as we have expected.

RQ3: Performance of ccgrep

It is interesting to know that our approach, i.e., token-based and naive sequential pattern matching, can be implemented fast enough for practical use. We have examined various queries for ccgrep with the target source files of Antlr and Ant in Java, and CBCD data (Git, PostgreSQL, and Linux Kernel) in C, and have measured the performance of ccgrep. Following are employed queries. All execution was made with the default setting of ccgrep except for the language option. qA: a < b? a: b Find ternary operation to give a smaller value. qB: T1 f(T2 a) { return $$; } Find function definition immediately returning a value. qC: f($$, $$, $$);

Find three parameter function.

qD:

for(a = 0; a < $$; a++) { $$ } $| a = 0; while(a < $$) { $$ a++; } Find for or (represented by $|) while statement with a control variable. Table 2 shows the size metrics of the target, the number of found snippets, and the execution time of each query on a workstation with Intel Xeon E5-1603v4 (@2.8GHz × 4), 32GB RAM, and Windows 10 Pro for WS 64bit.

As we can see from Table 2, the execution times are about 1-10 sec. even for a few million lines of Linux kernel target. We would think that those are fast and acceptable as a daily-use tool. The execution times for qA to qD are very stable for each target. For example, in the case of Linux, they are about 10 sec. even for the small #found case (48 for qA) and the large #found case (187,653 for qC). Thus, we would say that the execution time is not heavily affected by the result size (#found) but mainly affected by the target size (#line). Targets Ant in Java and PgSQL in C have similar sizes around 140-180 Klines, and the execution times are also similar around 1-1.5 sec. This would show that the execution time is not strongly affected by the target language.

For comparison to grep we have employed a query qE, that is almost equivalent to qA except qE does not match the targets with more than one line.

qE(grep):

([a-zA-Z ][a-zA-Z 0-9]*)\s*< ([a-zA-Z ][a-zA-Z 0-9]*)\s*\?\s* \1\s*:\s*\2
This query is complex and hard to create for inexperienced grep users. It has been executed by grep 3 to 9 times faster than ccgrep, but it missed some expected matches of the code snippets with two or more lines.

As the conclusion of RQ3, although the speed of ccgrep is slower than grep, it is sufficiently fast and acceptable as a search tool even for large targets such as 3 million LOC Linux kernel.

Related Works

There are numerous publications on code clone detection methods and their tools [START_REF] Rattan | Software clone detection: A systematic review[END_REF][START_REF] Roy | Comparison and evaluation of code clone detection techniques and tools: A qualitative approach[END_REF]. Most of those tools focus on finding all of the code clone pairs in the target file collection. They report all code clones or similar code snippets with similarities higher than a certain threshold. Precisely controlling the matches with meta-symbols like ours cannot be accomplished by those approaches.

There are several tools specialized for finding code snippets. CBCD has been designed for finding related code snippets from a buggy code snippet, by using matching of Program Dependence Graph (PDG) [START_REF] Li | Cbcd: Cloned buggy code detector[END_REF]. It can be used to find type 1, 2, and 3 clones; however, the matching generally requires a long preprocessing time to construct PDG, and so this approach would not fit the nimble clone finding that we are interested in. NCDSearch has been designed to find similar code snippets in the pile of source code files for the analysis of code reuse and evolution [START_REF] Ishio | Cloned buggy code detection in practice using normalized compression distance[END_REF]. The approach would be unique and interesting, but the speed is slower than ours. Micro-clones are recently getting focus due to their importance [START_REF] Beller | The last line effect explained[END_REF][START_REF] Islam | Comparing bug replication in regular and micro code clones[END_REF]. Our tool is one of the convenience tools for finding micro clones.

Siamese has been developed for finding code clone pairs for a query method or file using multiple representations of n-gram token sequences with inverted index [START_REF] Ragkhitwetsagul | Siamese: Scalable and incremental code clone search via multiple code representations[END_REF]. It requires a long indexing time (e.g., about 10 minutes indexing time for 10,000 method target). Thus its application and usage would be different from ours.

Variants of grep such as context grep cgrep, approximate grep agrep, and many others had been proposed and implemented to meet various requirements [START_REF] Abou-Assaleh | Survey of global regular expression print (grep) tools[END_REF]. However, there is no one for clone-based matching like ours. Semanticbased matching tool sgrep [START_REF] Bull | Semantic grep: Regular expressions + relational abstraction[END_REF], data-structure-based matching tool coccigrep [START_REF] Leblond | Coccigrep introduction[END_REF], and the logic-based query pattern capturing language [START_REF] Sivaraman | Active inductive logic programming for code search[END_REF] were proposed, where the specific notations for the queries are provided without using the notion of clones like ours.

Conclusions

We have presented ccgrep that effectively finds code snippets in the target files with the notion of code clone and meta-pattern. It is a practical and effective pattern matching tool, easy-to-use to many software engineers.

As a future direction, we are interested in further performance improvement by using more efficient pattern matching algorithms. Also, we are trying to spread the use of ccgrep to industry collaborators who are trying to detect similar bug patterns in their legacy systems. -Tokens starting with $ are meta-tokens and others are regular tokens.

-Wildcard meta-tokens $# and $$ match in reluctant way, and $*, $+, and $? match in possessive way [START_REF] Habibi | Java Regular Expressions: Taming the Java.util.regex Engine[END_REF].

-X, Y, X1, X2, ... are any regular token or a group with $( ... $).

Appendix: Formulating Matching

Here we formulate the matching made by ccgrep. The input of the matching is the query q, the target T of source code files in a programming language L, and matching option o. The output is a list of matched code snippet t in T . We refer to reserved words, delimiters (operators, brackets, ; ...), identifiers, and literals in L as regular tokens. Other tokens starting with meta symbol $ are called meta-tokens. q is a sequence of regular tokens and the meta-tokes, and each matched result t is a sequence of the regular tokens. These token sequences do not contain comments, white spaces, or line breaks. We always consider the matching on the token sequence level, not on the character level.

In Table 3, we define a token-level matching for various kinds of tokens with simple examples. The basic ideas of these matches are as follows.

-A language-defined token such as reserved words or delimiters matches the exact token. -A user-defined token such as an identifier or literal can match the same kind of token with a possibly different name or value. To pin down them to a specific identifier name or literal value, $ is used before the token. For example, $count would match only the token count. -Wildcard tokens $., $#, and $$ are introduced for the matches to any single token, any token sequence, or any token sequence discarding paired brackets, respectively. -Popular regular expression operators for choice, repetition, and grouping are introduced to enhance the expressiveness.

Consider that query q is a token sequence q 1 , ..., q m (1 ≤ m), and a target t is a token sequence t 1 , ..., t n (0 ≤ n). From q 1 to q m , if each token in the query matches tokens in the target from t 1 to t n as defined in Table 3 without overlapping or orphan tokens, then we say q matches t.

For the query token sequence q 1 , ..., q m and the target token sequence t 1 , ..., t n , if n = m and norm(q i ) = norm(t i ) for each i, then q matches t as type 2 matching. Here norm is a normalization function to flat the distinction of identifiers (or literals), defined below. special case of type 2 matching, with a constraint such that for any identifier or literal q i if q i = q j , then t i = t j , is Parameterized matching or P-matching. This is sometimes referred to consistent or aligned matching, meaning the same identifiers (or literals) in the query are mapped into the same ones in the target. P-matching is formally defined with a specialized normalization function norm p (), as follows.

norm p (x) ≡    #id pos(x) if x is an identifier #li pos(x) if x is a literal x otherwise Here, pos(x) is a function returning position i such that identifier (or literal) x is the i-th identifier (literal) newly appeared in the token sequence. Note that any meta-token starting with $ in the query and their matched tokens in the target are out of consideration of pos().

q2: a = 0; a = a + b; t2: y = 0; y = y + c; For q2, pos(a) = 1 and pos(b) = 2, and for t2, pos(y) = 1 and pos(c) = 2. q2 matches t2 as P-matching, because the P-normalized sequences are both [#id 1 , =, #li 1 , ; , #id 1 , =, #id 1 , +, #id 2 , ; ]. The following case is type 2 matching but not P-matching.

q3: a = 0; a = a + b; t3: y = 0; y = z + c; (type 2 matching but not P-matching) At t3, z cannot be matched by a because norm p (a) = #id 1 is not equal to norm p (z) = #id 2 . As a default of CC matching, P-matching is assumed but it can be changed by the tool's option.

RQ1:

  Query Expressiveness Are queries for various types of code clones expressible by ccgrep? RQ2 : Accuracy of ccgrep Does ccgrep accurately find various types of code clones already detected by other approaches? RQ3 : Performance of ccgrep What is the execution time of ccgrep? Is

  x is an identifier #li if x is an literal x otherwise In type 2 matching, an identifier in the query can match any identifier in the target, and also a literal in the query can match any literal in the target. q1: a = 0; b = 10; t1: x = 10; y = 200; q1 matches t2, because the sequences of the normalized tokens are both [#id, = , #li, ; , #id, =, #li, ; ].

Table 1 .

 1 Checked Clones in BigCloneBench

	Clone Type Clone Pairs Found Not Found
	Type 1	48116 48111	5
	Type 2	4234 4232	2
	Total	52350 52343	7

Table 2 .

 2 Target and Execution Result by ccgrep

	Target	Antlr	Ant	Git PgSQL	Linux
	Lang.	Java	Java	C	C	C
	#file	678 1,272	339	904	15,123
	#line	59,511 138,396 90,495 177,174 3,756,212
	qA #found	0	2	8	3	48
	time(sec.) 1.12	1.32 1.11	1.43	9.46
	qB #found	159	161	7	27	543
	time(sec.) 1.15	1.33 1.10	1.47	10.15
	qC #found	1,710 2,487 5,717 10,603 187,653
	time(sec.) 1.20	1.38 1.13	1.55	12.01
	qD #found	1	13	442	621	10,754
	time(sec.) 1.19	1.52 1.10	1.49	11.06
	Antlr: Antlr4 v.4.7.2, Ant: Apache Ant v.1.10.5, Git: v.1.6.4.3,
	PgSQL: PostgreSQL v.6.5.3, Linux: Linux kernel v.2.6.14rc2

Table 3 .

 3 Token-Level Matching X1 X2 ... $) X1, X2, ... (group for further regular expression operations) $( a++ $| ++a $) a++ †Type names are treated as identifiers. ‡Identifier and literal may match only the exact one by an option.

	token(s) in query matched token(s) in target	simple example of match
			query	target
	reserved word †	exact reserved word	while	while
	delimiter	exact delimiter	(	(
	identifier	any identifier ‡	myname	abc
	literal	any literal ‡	1	100
	$identifier	exact identifier	$myname	myname
	$literal	exact literal	$1	1
	$.	any single token	$.	if
	$# X	any shortest token sequence ending with X	$# +	while(f(a+
	$$ X	any shortest token sequence ending with X, excluding X
		inside well-balanced bracket {...}, [...], or (...)	$$ +	while(f(a+1))+
	X $-Y	either X or Y	+ $| -	-
	X $*	repeated sequence of X zero or more times	( $*	(((
	X $+	repeated sequence of X one or more times	( $+	((
	X $?	X or none	( $?	(
	$(

https://github.com/yuy-m/CCGrep

This can be changed by an option to allow inconsistent matching.

Acknowledgments This work was partially supported by JSPS KAKENHI Grant Number 18H04094, and Osaka University Program for Promoting International Joint Research. We are grateful for important comments from T. Kamiya, N. Yoshida, Raula Gaikovina Kula, E. Choi, K. Takenouchi, T. Kanda, and M. Matsushita.


Gogo Sébastien

Laggoun-Défarge Fatima
email: fatima.laggoun-defarge@univ-orleans.fr

Comont Laure

Disnar Défarge Christian

Hatton Gautret Pascale

How to assess cutover Peatland regeneration with combined organic matter indicators ?

Keywords: peatland, restoration, organic matter, bioindicator, management

When restored, cutover peatlands can favour biodiversity and carbon (C) sequestration. Within the EU program RECIPE, we aimed to identify combinations of site physico-chemical conditions, vegetation composition and below-ground microbiological characteristics that are beneficial to the long-term biodiversity and C sink function regeneration. To unreveal these characteristics, we assessed the bioindicator value of peat organic matter (OM) physicochemistry from cutover peatlands at various stages of regeneration. Although OM continues to reflect disturbances in the catotelm deep peat, we show that along the chronosequence the regenerated peat tends to be biochemically and physically similar to the one from the non exploited area of the same site. The combination of several indicators provides an efficient assessment of ecological conditions and makes valuable for the management of cutover peatlands.

INTRODUCTION

Peatlands are known to be important global sinks of carbon [START_REF] Clymo | Peat. In: Ecosystems of the World[END_REF]. However, human activities endanger not only the sink capacity, but also the long term storage of carbon within the ecosystem. Perturbations are numerous ranging from local and direct (peat cutting), to global and indirect (climate change). This paper focuses on the local direct effect of peat cutting. The main question raised after such perturbation is how and under what conditions the peat accumulation process can be induced again [START_REF] Chapman | Exploitation of northern peatlands and biodiversity maintenance: a conflict between economy and ecology[END_REF]. To provide management options that would preserve or enhance biodiversity for these abandoned peatlands, the European program RECIPE involved scientists from various domains of expertise working on peatlands located in Finland, France (2 sites), Switzerland and Scotland. In this paper, the results obtained from the study of Organic Matter (OM) quality in terms of peat biochemical and botanical composition are reported. Two approaches were used: 1) analyzes of peat profiles from different stages of regeneration illustrated by one of the studied peatlands: the Scottish site, and 2) experiments with a bioindicator as a response variable, in the four European sites. The aim of the first approach was to analyze peat OM evolution along the chronosequence. The aim of the second approach was to assess the effect of water table level and vegetation on peat chemistry (C/N) in each site.

MATERIALS AND METHODS

Study sites and sampling

For the first approach, the site was Middlemuir Moss in Scotland, an extensively exploited site from 1953 to 1998. One 0.5 m peat core was collected in four plots selected (Table 1) taking into account the age of abandonment and peat-forming key-species, i.e. Sphagnum and Eriophorum species. For the second approach, 4 sites were studied: 1) the Finnish site, Aitoneva where harvesting was abandoned in 1975; 2) the Russey site is a past (1968)(1969)(1970)(1971)(1972)(1973)(1974)(1975)(1976)(1977)(1978)(1979)(1980)(1981)(1982)(1983)(1984) industrially extracted peat bog located in the French Jura mountains; 3) the Baupte in France (Normandy) is a heavily industrially cut-over peatland ; and 4) the Scottish site, Middlemuir Moss. In each site, peat was placed in situ for 18 months in PVC tubes (n=3) and samples were analyzed after removing the peat monoliths from the tube.

(insert Table 1) First approach -organic matter analysis of the peat profiles Micromorphological identification and quantification of peat micro-remains were carried out using a photonic microscope under transmitted light [START_REF] Comont | Evolution of organic matter indicators in response to major environmental changes: the case of a formerly cut-over peat bog (Le Russey, Jura Mountains, France)[END_REF]. Carbon (C) and Nitrogen (N) contents were determined by combustion of dried and crushed samples using a CNS-LECO 2000 analyzer. Neutral monosaccharides were released after H 2 SO 4 hydrolysis and individual sugars were quantified by gas chromatography. The detailed procedure is given in [START_REF] Comont | Evolution of organic matter indicators in response to major environmental changes: the case of a formerly cut-over peat bog (Le Russey, Jura Mountains, France)[END_REF] Micromorphology analysis and C/N were conducted on bulk peat samples to reveal the influence of source materials on the OM composition while monosaccharide analysis was conducted on a fine-grained fraction of the peat (< 200µm) to obtain information on OM degradation processes [START_REF] Comont | Evolution of organic matter indicators in response to major environmental changes: the case of a formerly cut-over peat bog (Le Russey, Jura Mountains, France)[END_REF].

Second approach -Experimental design

In each selected site (SC, FR, FB, FI), an experiment was designed to assess the effect of vegetation and water table on peat chemistry. The experimental setting consisted of digging a large hole with a rising slope. PVC tubes containing peat were placed at two different water table levels and 3 key-species (S. fallax, E. vaginatum and E. angustifolium) were placed in the tubes for 18 months. Tubes without plants served as controls. The C/N quotient was used as a response variable in a 2 ways ANOVA with water table level and vegetation as main effects, followed by a Tukey post-hoc test (Statsoft, 2001).

RESULTS

First approach -OM bioindicators of the Scottish peat profiles

Micromorphology analysis showed that mucilage (a component derived partly from microbial syntheses) was dominant in the bare peat profile (Fig. 1a), but not in the colonized plots. Well preserved Sphagnum-derived tissues were recorded in the S. fallax area whereas amorphous OM and structureless tissues were recorded in the E. angustifolium area (Fig 1b,c). These two latter types of remains, especially the well preserved Sphagnum-derived tissues, are dominant at the peat surface in the advanced regeneration stage (Fig 1d).

(insert Fig. 1) Atomic C/N profiles were similar in bare peat and in the advanced regeneration stage treatment, noting a steeper decrease at 7.5 cm in the latter (Fig 2a,d). C/N ratio in the two early regeneration profiles was comparatively low at the surface (Fig 2b,c).

Second approach -C/N as a bioindicator used in experimental design

In all the sites, the water table level and its interaction with vegetation had no effect on C/N quotient (all F<1.8, all P>0.17). Vegetation had an effect on the Scottish and Le Russey peat chemistry (Fig 4, both F>7.1, both P<0.002): C/N in both Eriophorum plots was significantly lower than in the bare peat plot (Fig 4a,b). C/N in the S. fallax plot was not significantly lower than the bare peat plot in the Russey site (Fig 4a).

(insert Fig. 4) DISCUSSION/CONCLUSION All bioindicators showed a dramatic impact of colonizing vegetation on the structure and chemistry of newly formed peat. Cluster analysis on bulk C/N and total cellulosic sugar profiles (results not shown) showed that the advanced regeneration stage profile is more similar to bare peat than any other early regeneration stage. The two peat-forming plants investigated here differed by their decomposability: Sphagnum-derived tissues were preserved, whereas Eriophorum litter was quickly decomposed to structureless tissues and amorphous OM. Observations by cryo-scanning electron microscopy of the peat from a similar chronosequence in one of the studied sites (Le Russey) were in accordance with this result [START_REF] Comont | Evolution of organic matter indicators in response to major environmental changes: the case of a formerly cut-over peat bog (Le Russey, Jura Mountains, France)[END_REF]. With time, plant-derived OM becomes more heterogeneous with a notably better preservation of S. spp tissues (Laggoun-Défarge et al., in press). In the early regeneration stages, chemical and structural OM changes induced by colonizing plants seem to be accompanied by an increased rate of mineralization: at depth, monosaccharide concentrations were lower in the early regeneration stage than in both bare peat and the advanced regenerated profile. Francez (personal communication) showed that in deep peat carbon mineralization both in aerobiosis and anaerobiosis conditions is maximum after 10 to 20 years of regeneration.

The second experiment, involving vegetation and water table manipulation, provides some clues about what is occurring in early regeneration stages. In Scotland and Le Russey, there is a decrease in C/N quotient in vascular plants plots (probably due to rhizospheric processes) that might improve decay conditions. The vegetation effects seem to be related to the degree of site exploitation. Significant effects were observed in the Scottish site and in Le Russey, where peat cutting was either manual or extensive. Inversely no effects were observed in Finland and Baupte, where peat cutting was intensive.

TABLES AND FIGURES CAPTIONS Table 1. Regeneration stages and dominant vegetation of the sampling areas at Middlemuir (Scotland). Fig. 1. Mean depth evolution of relative percentages of organic remains of bulk peat in recent and advanced regeneration stages of Middlemuir peatland (Scotland) Fig. 2. Mean depth profiles of atomic C/N quotient of the peat fine-grained (<200 µm) fraction in the regeneration stages of Middlemuir peatland (Scotland).

(insert Fig. 2 )

 2 Monosaccharide analysis showed the molecular signature of source materials: rhamnose (Rha) and galactose (Gal) from S. fallax, and arabinose and xylose from E. angustifolium (Fig 3b,c) (Laggoun-Défarge et al., in press). These monosaccharides contributed to the composition of the advanced regenerated peat (Fig 3d). At depth of 7.5 cm and 25 cm, most of the monosaccharide concentrations in the early regeneration stage (S. fallax and E. angustifolium treatment) were lower than both bare peat and the advanced regeneration stage (Fig 3).

Fig. 3 .

 3 Fig. 4. Effect of vegetation (bare peat, E. angustifolium, E. vaginatum, S. fallax) on C/N quotient in experimental design in each country (± 1 standard error, n=3) (significant differences, P < 0.05, are shown by different letters)

  Figure 2.

  Figure 3.

  Figure 4.

TABLE Table

 Table

	1.
	Site	Time (y)			Vegetation (code on fig)
		since abandonment
	A	< 5			Bare peat (Bare peat)
	B	5 -10			Sphagnum fallax > 95% (S. fallax)
	C	5 -10
	FIGURES
	0%	50%	100%	0%	50%	100%	0%	50%	100%	0%	50%	100%
	Mucilage	Gelified + Oxidized Debris	Structureless plant tissues		Cuticles, spores, pollen
	Amorphous OM	Well-preserved plant tissues
	Figure 1.

E. angustifolium > 70%, E. vaginatum 5-10%, S. fallax 15-20% (E. ang) D > 50 S. palustre + S. fallax + S. capillifolium > 80%, Molinia caerulea (S. spp + herb.)

Statsoft, Inc. 2001. STATISTICA for Windows Version 6.0. Tulsa Oklahoma, Statsoft, Inc.

ACKNOWLEDGEMENTS

This paper is a contribution of the RECIPE project (reconciling the commercial exploitation of peat with biodiversity in peatland ecosystems) supported by the EU Commission (no. EVK2-CT-2002-00154).


Tuan-Anh Nguyen

Piseth Heng

Hugues Somja

Quang-Huy Nguyen

Numerical study of balcony deformations taking into account the presence of thermal break system

Keywords: Multi-fiber finite element, Thermal break systems, Thermal bridges, Combined torsional and flexural behaviours

This paper deals with the development of a numerical model for predicting the behaviour of the balcony in buildings equipped with internal insulation and thermal break systems while taking into account the torsional stiffness of the lintel and other restraints. In fact, the equipment of thermal break systems can help to limit the problem of thermal bridge formed through structural components of balcony-floor junction. However the balcony deflections become important comparing to the non-equipped case. The latter is computed in common practices by considering the balcony-floor structure as continuous beams, submitted to only bending-flexural effect. In some cases, the lintel can be used as an intermediary element to reduce the deflection of the balcony. This horizontal reinforced concrete (RC) beam is submitted to a combined loading of flexion and torsion, which requires specific numerical model to resolve.

In the proposed numerical modelling, the balcony-lintel-floor structure is represented by a beam grid model, in which the floor and balcony are divided into several bands perpendicular to the lintel. The lintel, considered as the main problem, is modelled using the finite element multi-fiber approach and the displacement-based formulation, which are capable of predicting the flexural and torsional behaviour of RC members. The same type of model with fewer degrees of freedom is also used to determine the flexural behaviours of the floor and that of the balcony. The thermal break behaviours are represented by a pair of rotational and axial springs in order to transmit the shear force and bending moment from the floor to the lintel. Another system of springs are also used to reproduce the axial and bending stiffness of the walls. While the efforts issued from the balcony and the walls can be determined explicitly, the presence of thermal break requires an iterative process to compute the displacement and rotation of the lintel.

Introduction

In buildings with internal and/or external insulation, thermal bridges occur at the connections between structural elements such as the balcony, walls and floor. These discontinuities of insulation provoke energy losses, increase the risk of local condensation and reduce the effectiveness of insulation. The presence of thermal bridges can be avoided with the equipment of thermal break systems, an element of low thermal conductivity placed at the building junctions to reduce the flow of thermal energy between structural components. Many types of thermal break systems are provided and suggested for different structural connections (wall-floor, balcony-wall-floor) and material designs (concrete-concrete, concrete-steel or concrete-timber structures) [START_REF] Ancon® | Isotec Thermally Insulated Balcony Connectors -Proceedings of the 2017 fib Symposium[END_REF][START_REF] Cohb Industrie® | SLABE Boîtier isolant structurel -Avis Technique 3[END_REF][START_REF] Isokorb® | Thermal bridging solutions with Schöck Isokorb® -Brochure[END_REF].

For building with internal insulation, in the case of balcony connectors, the presence of thermal break system might however increase the balcony deflections comparing to the non-equipped case (Figure 1a). In common practice, the latter is computed by considering the balcony-floor structures as continuous beams, submitted to only bending-flexural effect. In some common cases, especially with wall openings, the lintel can be used as an intermediary element to reduce the deflection of the balcony (Figure 1-b). This horizontal reinforced concrete (RC) beam is submitted to a combined loading of flexion and torsion, which requires specific numerical model to resolve. The balcony deformations therefore cannot be computed according to the common practice way and requires an improved method.

Figure 1. The presence of thermal break in the case of balcony connector.

In the proposed numerical modelling, the balcony-lintel-floor structure is represented by a beam grid model, in which the floor and balcony are divided into several bands perpendicular to the lintel. In other words, the complex three-dimensional structure is modelled using a simpler system of beam elements, in which the lintel is considered as the main element. The bending moment issued from the balcony and the floor creates a torsional effect in the lintel, which is modelled using the finite element multi-fiber approach and the displacement-based formulation. This approach has been widely used to correctly predict the flexural and torsional behaviour of RC members [START_REF] Bairan | Multiaxial-coupled analysis of RC cross-sections subjected to combined forces[END_REF][START_REF] Navarro-Gregori | A 3d numerical model for reinforced and prestressed concrete elements subjected to combined axial, bending, shear and torsion loading[END_REF][START_REF] Nguyen | An enhanced finite element model for reinforced concrete members under torsion with consistent material parameters[END_REF]. The same type of model with fewer degrees of freedom is also used to determine the flexural behaviours of the floor and that of the balcony.

The shear force and bending moment are transmitted from the floor to the lintel through the thermal break system, whose behaviours are represented by a pair of rotational and axial springs of elastic and/or elasto-plastic stiffness. Another system of springs are also used to reproduce the axial and bending stiffness of the walls. While the efforts issued from the balcony and the walls can be determined explicitly, the presence of thermal break requires an iterative process to compute the displacement and rotation of the lintel. These displacements are then defined as the boundary conditions to calculate the balcony deflections. The numerical results obtained by the proposed model are compared and evaluated with a solid finite element model simulated on ABAQUS software.

Model description

The proposed model has been developed with the intention to study the structure of balcony-lintel-wallsfloor-thermal break (Figure 2), for which the structural dimensions and parameters are shown in Table 1. According to the introduction, the structural components are modelled by two different ways:

-The balcony, lintel and floor: a beam grid-type model in which the floor and balcony are divided into several bands perpendicular to the lintel (Figure 3). Each band of beam is modelled by a multi-fiber finite element approach. -The walls and the thermal break system: a pair of rotational and axial springs of elastic and/or elastoplastic stiffness (Figure 4). The bending and axial effect of the wall are zero in the wall opening positions, therefore no spring is modelled. Being the main problem, the lintel is subjected to a combined loading of shear forces and torsional moments coming from the balcony and the thermal breakfloor combination, as well as from the walls. While the efforts from the balcony can be computed explicitly, the determination of the external efforts coming from the floor is not evident due to the presence of the thermal break. An iterative procedure is thus necessary in order to determine these efforts and then the sectional deformations of the lintel. The calculation procedure is summarized in Figure 5 and includes 3 steps:

1. Estimate the initial deflection v z l.0 and rotation θ x l.0 of the lintel in each band of beam. The numerical model for this step is called Lintel Model 1.

2. At the first iteration, taking l,k 1 l,0 zz vv   and l,k 1 l,0 xx     .Then, using theses lintel deformations as the boundary conditions, the values of shear force V z S.k and bending moment M x S.k retained from the thermal breakfloor system to the lintel are determined in each band of beam using the second numerical model called Slab Model.

3. Applying the efforts V z S.k and M x S.k obtained from previous step to the third numerical model (called Lintel Model 2), the new lintel deformations v z l.k+1 and θ x l.k+1 can be determined in each band of beam. The Lintel Model 2 is very similar to the first one, except that the effect coming from the thermal breakfloor system (shear force V z S and spring stiffness k θx S ) is replaced by a couple of torsional moment and shear force.

The convergence criterion is determined by calculating the relative error of lintel deformations:

l,k 1 l,k l,k 1 l,k z z x x v l,k l,k zx vv ; v            (1.1)  If

Model formulations

Lintel Models

According to the model description, the proposed model contains two types of Lintel Model: the first one is used in the 1 st step and the second one is used in the 3 rd step. The only difference between these two types is the applied efforts issue from the thermal breakfloor system. The Lintel Models are developed using a two-node Timoshenko beam based on the principle of multi-fiber finite element approach, in which a system of integration points (called fiber) is obtained at the intersection of the longitudinal fibers and some control cross-sections along the element (Figure 6). Each fiber is considered as a material point, has its own coordinates, surface and an appropriate material law in order to determine the strain and stress from the element displacements. Using displacement-based formulation, the internal and nodal efforts, as well as the stiffness matrices, are determined from the generalized and nodal displacements with the aid of numerical integrations and the Gauss-Lobatto interpolation method. The Lintel Models contain the entire beam of lintel and eventually the mullions at two ends. These beam models are then divided into several elements whose number is defined according to the band of beam (Figure 7). Taking into account the combination of bending and torsional moments, the Lintel Models have 6 degrees of freedom at each element node, resulting a 12x12 stiffness matrix in each element. Each band of lintel is subjected to the external effects from the balcony, walls, mullions and thermal breakfloor system. In the 1 st step the thermal break effect is not taken into account, and a spring with rotational stiffness is used to represent the bending moment effect from the floor applied in the Lintel Model 1 (Figure 8). In step 3, the effects from thermal breakfloor system applied to the lintel are represented by a couple of shear force V z S and torsional moment M x S , obtained from step 2 (Figure 9). The superscripts m, w and f indicate mullion, wall and floor, respectively. The values of theses complementary stiffness are defined as follows (Table 2):

EA k H EI k 3 (pinned) H EI k 3 (pinned) H      ff f cx x f EI k3 L  

Slab and Balcony Models

According to the model description, the Slab Model is used in step 2 to represent the behaviour of thermal breakfloor system. By defining the lintel displacements obtained from step 1 as the boundary conditions, this model determines the values of shear force V z S.k and bending moment M x S.k retained from the thermal breakfloor system to the lintel (Figure 10). At the end of the iteration process, at each band of beam, the lintel displacements are defined as the boundary conditions in the Balcony Model to determine the balcony deflections (Figure 5 and 11). Each band of the floor as well as the balcony are modelled on the same principle using a two-node Timoshenko beam based on the multi-fiber finite element approach and displacement-based formulation, similar to the Lintel Models. However, knowing that this type of model is used to represent the behaviour of the thermal breakfloor system and the balcony, which are subjected to bending flexural effects, only 3 degrees of freedom are necessary at each element node. This is the reason why in each cross-section layer discretization is applied, instead of square fiber discretization. The beam formulations of these models are similar to those of the Lintel Models with only a few differences in the kinematic equilibrium. On the other hand, the thermal break is modelled by a pair of axial and rotational springs with elastic or elasto-plastic stiffness. Knowing that the multi-fiber model of the floor contains 3 degrees of freedom in each element node, the element stiffness matrix of this element is expressed as follows:

0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 k 0 0 k k 0 k k 0 0 k 0 0 k 0 k k 0 k k KK 0 0 0 0 0 0 0 0 0 0 0 0 0 k 0 0 k 0 0 k k 0 k k 0 0 k 0 0 k 0 k k                         TB TB TB 2 21 22 0 k k             (1.3)
Where TB TB zx k ,k  are the axial and rotational elastic resistance of the thermal break, respectively, while TB TB TB TB 11 12 21 22 k ,k ,k ,k are the components of the elasto-plastic stiffness matrix.

Numerical results

In this section, several numerical examples are carried out for a structure in real condition containing the elements of balconylintelwallsfloor and the thermal break SLABE BZ (COHB Industrie® 2019), manufactured by COHB Industry, France. The dimensions of structural elements are represented in Figure 13, in which several balcony widths varied from 2 m to 12 m are considered. Only the case of no wall openings is considered in this paper. The numerical results are obtained by the proposed model in the elastic domain and then compared to a solid finite element model simulated on Abaqus, in which the thermal break system is simulated by the Spring/Dashpots option. The value of elastic modulus is rounded to 10e3 MPa in order to take into account the effect of creep and crack in concrete. In Eurocode 2, under the serviceability limit state and taking into account a value of 0.3 for the  factor, the quasipermanent combination of actions on the balcony and on the floor are 7.05 kN/m and 6 kN/m, respectively. It is important to note that the value of variable action Qf is not considered in order to obtain the most unfavourable value of balcony deflection.

Figure 13. Dimension of studied structure.

Thermal break and lintel effect

In the case without the presence of thermal break and lintel (configuration 1), the common practice method uses a beam element to represent the behaviour of studied structure, in which the balcony has a positive deflection upward (Figure 14). While the thermal break system is taken into account (configuration 2), the common practice method gives a negative deflection downward, whose value is very important and exceeds the limit state of deflection (Figure 15). The common practice method, however, cannot consider the lintel effect on the moment transmission between the floor and the balcony: part of negative moment coming from the thermal breakfloor system is resisted by the lintel, due to its capacity of torsional resistance (Figure 17). As a consequence, using the proposed method, the value of balcony deflection reduces from 52 mm according to common practice method to 1 mm, thus satisfying the limit state of deflection (Figure 18).

Structure behaviour

In accordance to the practice requirement, the structure behaviour is studied in function of the balcony width. The numerical results are presented in Table 3, for both case of solid model ABAQUS and proposed model, in which only the maximum values at the central band are represented. We can observe that the values of lintel displacements and balcony deflection vary with the balcony width, and reasonable agreements are obtained in most cases effects. As the grid-beam model is in fact more a "band" model, it does not take into account the effect of bending and stress distribution in the transversal direction in the slab and in the walls, and therefore its deflections are bigger than the one obtained with ABAQUS. The relative differences of numerical results between two models decrease with increasing the balcony width. The distributions of balcony deflection across its width are shown in Figure 19, in which the solid model ABQUS always gives a parabolic shape for every balcony width. On the other hand, for short balcony widths (2 and 3 m), the balcony deflection distributions also have a parabolic shape, but become nearby constant in the middle for large balcony width (6 and 12 m). The variation trend of the balcony deflections in function of its width is also represented in Figure 20, in which the maximum value of balcony deflection obtained by proposed model tends to reach a constant value by increasing the balcony width.

Conclusion

This paper introduces a beam grid model modelling the building behaviour in the presence of thermal break system. The proposed model is simple but effective in predicting the balcony deflection taking into account the torsional resistance capacity of the lintel, which cannot be computed using common practice methods. Good agreements on the numerical results compared to a solid finite element model simulated on ABAQUS prove the accuracy of the proposed model on the elastic linear range. Further studies on the inelastic range will be carried out in order to evaluate the application of this model in practical conditions.

Figure 2 .

 2 Figure 2. General structure of balcony-lintel-walls-floor-thermal break.

Figure 3 .

 3 Figure 3. Beam grid model for the balcony-lintel-floor system.

Figure 4 .

 4 Figure 4. Pair of springs modelling the walls and thermal break system effect.

  , the iteration process is done; tol tol v ,   are the tolerance limits.  If not, back to step 2 and taking l,

Figure 5 .

 5 Figure 5. Summarize of the proposed model.

Figure 6 .

 6 Figure 6. Principle of multi-fiber finite element modelling and section discretization of Lintel Models.

Figure 7 .

 7 Figure 7. Finite element modelling of lintel.

Figure 8 .

 8 Figure 8. Applied efforts and additional springs in the Lintel Model 1.

Figure 9 .

 9 Figure 9. Applied efforts and additional springs in the Lintel Model 2.

Figure 10 .

 10 Figure 10. Slab Model -plan view xy.

Figure 11 .

 11 Figure 11. Balcony Models.

Figure 12 .

 12 Figure 12. Principle of multi-fiber finite element modelling and section discretization of Slab and Balcony Models.

Figure 14 .

 14 Figure 14. Configuration 1 -Without the presence of thermal break and lintel.

Figure 15 .

 15 Figure 15. Configuration 2 -Without the presence of lintel.

Figure 17 .

 17 Figure 17. Torsional moment resisted by the lintel.

Figure 18 .

 18 Figure 18. Configuration 3 -With the presence of thermal break and lintel.

Figure 19 .

 19 Figure 19. Distribution of balcony deflection across its width. Figure 20. Variation trend of maximum balcony deflection in function of its width.

Table 1 .

 1 The parameters of studied structure.

	Balcony	Walls	Lintel	Floor	Thermal break
	Length Lb	Height H	Height tl	Length Lf	Width
	Width lb	Thickness e	Width e (= the	Thickness tf	Thickness es
	Thickness tb	Mullions width Lm	wall thickness)
		Wall openings

Table 2 .

 2 Spring stiffness.

					Mullions		Walls	Floor
	k	m z		m c EA H		w z	w c
	k	m x 		3	mm cx EI H	(pinned)	w x	ww cx
	k	m y 		3	mm cy EI H	(pinned)	w y	ww cy

Table 3 .

 3 Numerical results obtained by proposed model and solid model ABAQUS.

		Lintel deflection (e-6 m)	Lintel rotation (e-4 rad)	Balcony deflection (e-3 m)
	Balcony	Solid model	Proposed	Solid model	Proposed	Solid model	Proposed
	width (m)	ABAQUS	model	ABAQUS	model	ABAQUS	model
	2	-24.00	-21.83	1.71	2.20	-1.02	-1.04
	3	-24.00	-22.52	2.01	2.45	-1.06	-1.08
	6	-24.00	-22.46	2.38	2.58	-1.12	-1.10
	12	-23.90	-22.47	2.49	2.58	-1.15	-1.10


Hong Hanh Le

Piseth Heng
email: piseth.heng@insa-rennes.fr

Clemence Lepourry

Hugues Somja

Experimental behaviour of an innovative demountable balcony with sophisticated connection

Keywords: Demountable steel balcony, Embedded H-profile anchorage system, Hybrid bolted joints, Concrete contact pressure

For a general practice, reinforced concrete balconies are permanently fixed and simultaneously erected onsite with the rest of the structures in the buildings. This practice is problematic in the viewpoint of the onsite security, the speed of construction, and the maintenance of the balcony and the building. This problem calls for an innovative solution of a demountable balcony that has been conceptualized by INGENOVA, an R&D office of a French company GROUPE LEGENDRE. In the proposed system, the balcony is supported by H-profile cantilevers that are connected to the embedded H-profiles in the reinforced concrete slab by bolted joints. The design of the connection of the proposed balcony to the concrete slab, particularly the embedded H-profiles, requires an experimental characterization. This paper presents an experimental investigation of the behaviour of the innovative balcony system through a series of experimental tests on large-scale specimens. The main objectives of these tests are to quantify the local behaviour (distribution of concrete pressures onto embedded H-profiles) as well as the global behaviour (the bearing capacity as well as the deformability). The test results show that the failure mode of the specimen is governed by a punching failure of the concrete or by the rupture of steel bolts in the joint, following the configurations. Furthermore, the distribution of the concrete pressures on the embedded profiles obtained from the tests provides reference results for future development of the analytical design.

Introduction

Balcony is an essential architectural element that provides more comfort to the people living in an apartment building. The balcony may experience damages due to constantly being exposed to the weather and therefore needs regular maintenance. Typical reinforced concrete balconies are usually erected onsite simultaneously with other structural elements and permanently fixed during the whole life of buildings. This practice on one hand slows down the construction process and on the other hand causes difficulties for the maintenance of the balcony and the building.

INGENOVA, an R&D office of a French company GROUPE LEGENDRE, in collaboration with INSA Rennes has conceptualized an innovative steel balcony that is supported by H-profile cantilevers connected to an anchorage system by hybrid bolted joints (Figure 1). The anchorage system is composed of reinforcement rebars and a steel module that contains H-profiles welded to an edge beam at the exterior end and to a steel tube at the other end. The detail of bolted joint is given in Figure 1c. This balcony system is therefore demountable, allowing an accelerated construction of concrete floors and walls as the balcony can be installed at the end of the construction phase, as well as providing a convenient accessibility for maintenance. In addition, the anchorage system of the balcony is simpler and hidden in the slab, making the structure more aesthetic compared to that of typical steel balconies. However, the load transfer mechanism between the H-profile cantilevers and the concrete slab through the bolted joints is not straightforward. The pressure distribution of the embedded profiles onto the concrete is not fully known. The investigation of the concrete pressure on embedded profiles can be referred to the study by [START_REF] Mattock | Strength of embedded steel sections as brackets[END_REF] who performed an analytical and experimental study of the strength of steel sections embedded in a reinforced concrete column as brackets. They made a simplification of the compressive stresses on the concrete below and above the embedded sections with an experimental validation in order to propose the analytical model for the design. On the other hand, Corley and Hawkins (1968) performed experimental tests of concentrically loaded slab-column specimens containing shearhead reinforcement made from structural shapes. A design procedure for shearheads at interior supports was then proposed based on the experimental results. However, these studies do not present the same situation as in the case of the embedded profiles in this study. Therefore, the design of the connection of the proposed balcony to the concrete slab, particularly the embedded H-profiles, requires an experimental characterization.

The objective of the present paper is to describe an experimental study on a series of large-scale specimens of the balcony system in order to quantify the local behaviour (distribution of concrete pressures onto embedded H-profiles) as well as the global behaviour (the bearing capacity as well as the deformability).

Experimental testing

Test setup

The test setup was designed to represent a concrete floor-to-balcony connection (Figure 2a). In order to have a simple test setup and a representation of the in-situ moment diagram (Figure 2b), the floor was simply supported at the theoretical inflection point while the load was applied at the free extremity of the cantilever (Figure 2c).

The test setup consisted of a specimen of the balcony, a framed back support, two front supporting columns, two lateral bracings, a force jack with a capacity of 1500 kN, and a loading cross-beam to distribute the load from the jack onto the cantilever beams (Figure 3). In this test setup, the specimen was first placed on the two front supporting columns with a contact surface of 300mm-by-160mm and on the mobile UPN200 cross-beam of the framed back support (see detail B in Figure 3b). The specimen was then put into contact with the HEA200 cross-beam of the framed back support by adjusting the level of the UPN200 cross-beam. Two lateral bracings were also installed in order to limit the lateral buckling of the profiles. Two layers of PTFE material were installed between the lateral bracings and the cantilever steel H-profiles to reduce friction. The loading was applied vertically by the force jack on the two cantilever profiles through the loading cross-beam.

Test specimen

In order to quantify the contribution of the joint, the edge steel beam and the lintel drop, three specimens were fabricated and tested. The first specimen (C1-A) consisted of two HEB120 profiles welded to a steel tube with a section of 50×50×3 mm and encased in a reinforced concrete slab (see Figure 4a). The specimen C1-B had the actual configuration of the balcony concept (Figure 4b). It was composed of two embedded HEB120 profiles, welded to a steel tube with a dimension of 50×50×3 mm at one end and to a steel edge beam at the other end, two HEB200 cantilever beams (each welded to an end plate with a dimension of 290×200×20 mm), bolted joints connecting the cantilevers to the embedded steel part, and a reinforced concrete slab with a thickness of 200 mm. The joint was composed of 6 M20 bolts with a grade of 8.8 fixing through the steel edge beam to 6 embedded threaded sleeves, which are welded to the edge beam (Figure 4d). The last specimen, called C1-C, had the same configuration as specimen C1-B except for the presence of the RC lintel drop with a height of 200 mm (Figure 4c).

Material properties

The concrete grade was C25/30. The compressive strength of concrete was determined according to NF EN 12390-3. Three 110 x 220 mm cylinder specimens were tested at around 28 days of age and three others at the time of testing. The results are given in Table 1, in which and are the mean value of compressive strength of the concrete and the corresponding standard deviation, respectively. For steel materials such as the HEB200 profile and the rebars, at least three coupon tests were made according to EN ISO 6892-1 in order to determine the actual characteristics, the results of which are reported in Table 2.

, , , and are the mean value of yield strength, the standard deviation of yield strength, the mean value of ultimate strength, the standard deviation of ultimate strength, respectively.

Instrumentation

The Apart from the displacement sensors, strain gauges were used to measure the deformation of the embedded HEB200 profiles at the locations of 30 mm, 80 mm, 180 mm, 280 mm and 380 mm from the front side of the concrete slab (see Figure 6). For specimen C1A, 40 gauges were used in total, meaning 20 gauges for each H-profile. For specimens C1B and C1C, strain gauges on the bottom flanges at the first two sections could not be installed due to the existence of the lateral stiffeners. Consequently, only 32 gauges were used, 16 gauges for each H-profile.

(a). Positions of the strain gauges.

(b). Photo of the strain gauges.

Figure 6. Strain gauges (dimensions in mm).

Test procedure

The load was applied according to the test procedure described in Annex B of Eurocode 4 part 1-1 ( 2004). Each test specimen was subjected to 25 loading/unloading cycles between 40 % and 5 % of the expected failure load, followed by a cycle in which the load was increased to the estimated ultimate value before being loaded to failure (see Table 3). The load was applied at a constant rate of 3mm/min during the first 3 cycles and was maintained afterwards at 6mm/min.

Experimental results

Failure mode

Figure 7 shows the evolution of the force in function of the elongation of the force jack for the three tests. With respect to the specimen C1A, cracks started to appear during the initial 25 cycles of loading (5 kN -25 kN) on the bottom surface of the concrete slab, right under the H-profiles (Figure 8a). These cracks then propagated towards the back of the slab with the increase in the load applied. During the cycle between 5 kN and 50 kN, inclined cracks appeared on both sides of each profile (Figure 8b and Figure 9), corresponding to a punching shear phenomena. Inclined cracks were also noticed on the lateral sides and on the bottom surface of the slab (Figure 10). Cracks due to bending behaviour of the slab were only seen at a higher applied load, close to the failure one (Figure 11). The failure happened when the applied load stopped increasing at around 125 kN and excessive opening of inclined cracks on the lateral sides were observed. The specimen failed in punching shear at the supports. For tests C1B and C1C, the punching shear phenomena were also observed at the supports of the concrete slab but with lower intensity (Figure 12). In addition, cracks also developed along the edge of the slab, causing the separation between the concrete slab and the steel edge beam (Figure 13). In the case of specimen C1C where a reinforced concrete lintel drop is present, vertical cracks were seen on both exterior and interior surfaces of the lintel since the first loading cycle (Figure 14). In both tests C1B and C1C, the failure occurred at the bolted joints (Figure 15). In test C1B, a bolt on the right side of the top row of the joint at the right profile was broken when the load reached approximately 210 kN, which prompted a sudden drop of load to around 165 kN. In test C1C, two bolts of the top row of the joint at the right profile were broken simultaneously at a load of 205 kN.

Deflection of the HEB200 profile

The deflection of the cantilever H-profiles at the applied load location in function of the applied force per one profile in the three tests is shown in Figure 16. In case of test C1B, the measured displacement data provided by the LVDTs are only reliable up to 92 kN. The experimental setup was unable to measure the system response for higher values. In fact, the maximal forces resisted by specimens C1B and C1C are approximately equal to 104 kN and 102 kN respectively, 65% higher than the load supported by specimen C1A (62 kN). It is clear that the presence of the steel edge beam increases significantly the bearing capacity and the stiffness of the structure.

Distribution of bending moment along the embedded H-profile

The bending moment in the embedded H-profiles can be determined from the strain values measured with strain gauges placed on their surfaces. By assuming that the strain varies linearly along the height of the section, it is possible to determine the strain distribution over the cross section of the profile (Figure 17). Within the elastic domain, the normal stress is calculated from the strain using Hooke's law. Beyond the elastic limit, the normal stress is determined based on the stress-strain relationship obtained from tensile tests. The bending moment acting on the section can be computed as:

(1)

where is the distance from the neutral axis. Figure 18 represents the comparison of the bending moment acting in the H-profiles for the three tests.

The bending moment at the first two sections are missing in tests C1B and C1C due to the lack of data on the strain at the bottom flange of the profiles. It can be noted that the bending moment in the embedded H-profiles in test C1A is about two times larger than in test C1B. On the other hand, the bending moment obtained in test C1C is about 30% to 50% higher than in test C1B.

Conclusion

A series of three experimental tests on large-scale specimens was carried out in order to study the behaviour of a novel demountable steel balcony system. The test results show that the failure mode of the specimens is governed by a punching failure of the concrete in the case of test C1A and by the rupture of steel bolts in the joint in tests C1B and C1C. The presence of the steel edge beam in test C1B seems to improve the load transfer from the balcony to the reinforced concrete slab, as the applied bending moment is lower compared to test C1A for the same level of loading. On the other hand, the lintel drop in test C1C seems to provide a vertical reaction, which in turn increases the negative bending moment in the embedded profiles.

These tests could also quantify the bearing capacity and the deformability of the systems, providing reference results for the improvement of the design approach. The next step involves the development of a numerical modelling of the tests in order to gain a deeper understanding of the system behaviour. This model can be used in a parametric study of important parameters, the result of which will be exploited to develop a design approach for the embedded profile.

  . Detail of the hybrid bolted joint.

Figure 1 .

 1 Figure 1. System of the innovative demountable steel balcony.

Figure 2 .

 2 Figure 2. Specimen design: (a). Configuration of real loads on floor-to-balcony connection. (b). bending moment diagrams. (C). Configuration of testing.

Figure 3 .

 3 Figure 3. Test setup.

  . Detail of the joint.

Figure 4 .

 4 Figure 4. Test specimens (dimensions in mm).

  force generated by the hydraulic jack was measured with 3 force sensors: a DELTECH ± 200 kN and a double scale sensor ± 500 kN and ± 1500 kN. 4 LVDTs were used to measure the vertical displacements of two steel profiles (Dv1 to Dv4) and 11 LVDTs were installed to measure the vertical displacements of the reinforced concrete slab (Dv5 to Dv15). The position of the LVDTs are shown in Figure 5. Measured data were recorded every half second by a data acquisition system. Three extra LVDTs were also added in tests C1B and C1C in order to measure the opening between the edge beam and the concrete floor.

  (a). Positions of the sensors. (b). Photo of the sensors.

Figure 5 .

 5 Figure 5. Displacement sensors (dimensions in mm).

Figure 7 .

 7 Figure 7. Force-displacement curve at the force jack.

Figure 8 .

 8 Figure 8. Test C1A: cracks on the bottom surface of the reinforced concrete slab.

Figure 9 .

 9 Figure 9. Test C1A: inclined cracks on the front surface of the reinforced concrete slab.

Figure 10 .

 10 Figure 10. Test C1A: inclined cracks on lateral and on the bottom surfaces of the reinforced concrete slab.

Figure 11 .

 11 Figure 11. Test C1A: Vertical cracks at the middle span of the slab.

Figure 12 .

 12 Figure 12. Test C1B: cracks due to punching shear.

Figure 13 .

 13 Figure 13. Crack due to the separation between the concrete slab and the steel edge beam.

Figure 14 .

 14 Figure 14. Test C1C: vertical cracks on the concrete lintel.

Figure 15 .

 15 Figure 15. Test C1B: deformation of the gusset and position of the broken bolt.

Figure 16 .

 16 Figure 16. Deflection of the HEB120 profile at the applied load in function of force per profile.

Figure 17 .

 17 Figure 17. Strain and stress distribution over the height of the profile section within the elastic domain.

  (a). Test C1A versus test C1B. (b). Test C1B versus test C1C.

Figure 18 .

 18 Figure 18. Distribution of bending moment in the embedded H-profile.

Table 1 .

 1 Compressive strength of the concrete.

	Specimen	Test date Age (days)	[MPa]	[MPa]
	C1-A	16/01/2020 26/02/2020	30 71	28.8 36.9	1.2 1.0
	C1-B	20/01/2020 10/03/2020	31 81	30.7 41.7	1.9 1.0
	C1-C	02/03/2020 11/06/2020	28 129	34.5 42.6	0.3 1.2

Table 2 .

 2 Properties of steel materials.

				Yield strength	Ultimate strength
	Element	Number	MPa	MPa	MPa	MPa
	HEB 120	Flange Web	6 3	395.5 386.9	7.7 16.3	515.1 509.9	7.0 6.7
		HA8	3	467.0	31.1	621.2	14.8
	Rebar	HA10	3	457.9	72.1	550.1	14.3
		HA12	3	513.5	26.8	598.9	19.7

Table 3 .

 3 Expected value of ultimate and failure loads.

	Test	Ultimate [kN] Failure [kN]
	C1A	50	65
	C1B	85	130
	C1C	160	210

Acknowledgements

The authors gratefully acknowledge financial support by the ANR (Agence Nationale de la Recherche, France) through the project LabCom ANR B-HYBRID.