Taro Kimura
email: taro.kimura@cea.fr

Masaki Murata
email: m.murata1982@gmail.com

Current reflection and transmission at conformal defects: Applying BCFT to transport process

We study reflection/transmission process at conformal defects by introducing new transport coefficients for conserved currents. These coefficients are defined by using BCFT techniques thanks to the folding trick, which turns the conformal defect into the boundary. With this definition, exact computations are demonstrated to describe reflection/transmission process for a class of conformal defects. We also compute the boundary entropy based on the boundary state.

Introduction

A wide range of physicists -cosmologists, condensed matter physicists, and particle physicists -have been attracted by anomalous scaling behavior of matter caused by critical phenomena. Studying critical phenomena with conformal defects is of great interest, because most of realistic situations inevitably contain impurities. A powerful method for studying critical phenomena with conformal defects is boundary conformal field theory (BCFT). There are many applications of BCFT especially to one-dimensional quantum systems with impurities, e.g., the Heisenberg spin chain, the Kondo model, and so on. See [START_REF] Affleck | Quantum impurity problems in condensed matter physics[END_REF] for a review along this direction. However, it has not been completely understood how BCFT describes the reflection/transmission at conformal defects. For this purpose, Quella, Runkel, and Watts proposed the reflection/transmission coefficient to characterize the transport phenomena at the conformal defect [START_REF] Quella | Reflection and transmission for conformal defects[END_REF]. Their proposal is quite natural and generic in the sense of CFT because their coefficients are based on the gluing condition for the energy-momentum tensor. However, it is not obvious how the proposed coefficient is related to transport coefficients used in other contexts, such as quantum wire junctions and experiments. Our goal is to further investigate the meaning of the proposed reflection/transmission coefficient and to obtain a more detailed description of the reflection/transmission process.

In this paper, we define the reflection/transmission coefficient for conserved currents, as a natural generalization of that proposed in [START_REF] Quella | Reflection and transmission for conformal defects[END_REF] and also in [START_REF] Bachas | Permeable conformal walls and holography[END_REF]. Our definition involves current algebras and boundary states, which characterize boundary conditions of fields at conformal defects. We demonstrate exact computations for two systems: the system having permutation boundary conditions and the system partially breaking the SU(2) k 1 × SU(2) k 2 symmetry into the SU(2) k 1 +k 2 . Our definition also reveals which current penetrates the conformal defects as well as how much it does. In addition, we compute the boundary entropies to identify the amount of information carried by the boundary. In general, it is difficult to distinguish the contributions of the boundary and the bulk CFTs to the entropy. In our analysis, since the boundary state is explicitly constructed, we can separate them more efficiently, and obtain results consistent with previous works.

Reflection and transmission coefficients

We shall briefly review the reflection/transmission coefficient proposed in [START_REF] Quella | Reflection and transmission for conformal defects[END_REF] and give a more detailed meaning to that. That is to say, we claim that the proposed reflection/transmission coefficient corresponds to the energy transport. Besides, by generalizing their proposal, we define the reflection/transmission coefficient for a conserved current with conformal weight h = 1.

Conformal defect and the junction

We consider two one-dimensional quantum systems connected by a junction, which can be considered as an impurity interacting with the bulk. Let us assume that the first system is in the positive domain x > 0, the second is in the negative x < 0, and they are connected at the origin as depicted in Fig. 1(a). If these systems obey symmetry algebras A i , the Hamiltonian density for each domain is obtained by Sugawara construction at the conformal fixed point1

H 1 (x) = 1 2π(k 1 + h ∨ 1 ) d 1 AB J 1,A (x)J 1,B (x) (x > 0) (2.1) H 2 (x) = 1 2π(k 2 + h ∨ 2 ) d 2 AB J 2,A (x)J 2,B (x) (x < 0) (2.2)
where d i AB is the inverse of the Cartan-Killing form and h ∨ i is the dual Coxeter number of the algebra A i . The current J i,A takes value in the Lie algebra A i and the index A runs over A = 1, • • • , dim A i . In general, A 1 and A 2 can be different algebras. The Fourier modes of J i,A satisfy the Kac-Moody algebra A i : Fig. 1. From the impurity to the defect. (a) Two one-dimensional systems are connected through the impurity at x = 0. (b) Adding the time direction and taking the continuum limit, that system is mapped into the two-dimensional system with the defect along the line x = 0.

j i,A m , j i,B n = f i AB C j i,C n+m + k i md i,AB δ m+n,0 , (2.3)
where f i is the structure constant of A i and k i is the level of A i . Especially for the SU( 2) theory, this level corresponds to the electron spin as k = 2s for the multi-critical spin chain [START_REF] Affleck | Exact critical exponents for quantum spin chains, nonlinear σ -models at θ = π and the quantum hall effect[END_REF][START_REF] Affleck | Critical theory of quantum spin chains[END_REF] and to the number of channels for the Kondo model [START_REF] Affleck | A current algebra approach to the Kondo effect[END_REF][START_REF] Affleck | The Kondo effect, conformal field theory and fusion rules[END_REF][START_REF] Affleck | Critical theory of overscreened Kondo fixed points[END_REF][START_REF] Affleck | Conformal field theory approach to the Kondo effect[END_REF]. Note that the anti-holomorphic parts satisfy the same Kac-Moody algebras.

In general, the impurity breaks the symmetry of the bulk theory, and couples to a common subalgebra C of A 1 and A 2 . One possibility for the interaction term is

H int (x) = δ(x)d ab λ 1 J 1,a + λ 2 J 2,a S b , ( 2.4)
where λ i are the coupling constants and J i,a takes value in the subalgebra C. Here, S a stands for the impurity spin and d ab is the Cartan-Killing form for C. For this kind of interaction, as well discussed in the Kondo problem, we can complete the square by shifting the current J i,a = J i,a + 2πS a δ(x) when the coupling constant takes the critical value. Then we obtain a quadratic Hamiltonian again. This observation indicates the existence of a non-trivial conformal fixed point at low energy with the impurity spin absorbed. We remark that although (2.4) is written in terms of the currents, there are models whose interaction terms should be written in terms of fundamental fields rather than currents, e.g., the spin chain with a single impurity model [START_REF] Eggert | Magnetic impurities in half integer spin Heisenberg antiferromagnetic chains[END_REF]. Even in such a case, it is expected that the conformal fixed point obtained by the RG flow is described by the Hamiltonian (2.1) and (2.2) with boundary conditions, which are specified in the following sections. Now we shall describe the above system in terms of BCFT. Corresponding to the two quantum systems, the BCFT picture involves two CFTs: CFT 1 and CFT 2 . These CFTs are defined in the upper and lower half planes respectively as depicted in Fig. 1(b). The real axis, which divides the two CFTs, stands for the world line of the impurity, or the defect. We can reformulate this system to obtain CFT 1 × CFT 2 in the upper half plane thanks to the folding trick [START_REF] Wong | Tunneling in quantum wires: a boundary conformal field theory approach[END_REF][START_REF] Oshikawa | Defect lines in the Ising model and boundary states on orbifolds[END_REF][START_REF] Oshikawa | Boundary conformal field theory approach to the critical two-dimensional Ising model with a defect line[END_REF], as shown in Fig. 2. In this way, the junction of the one-dimensional quantum systems can be mapped into a CFT boundary condition.

Energy reflection and transmission

Let us then introduce the reflection/transmission coefficient to characterize the transport phenomena at the conformal defect. For this purpose, there are two key ingredients. The first is a boundary state. The boundary state is a state of BCFT which characterizes a boundary condi-Fig. 2. From the defect to the boundary. By using the folding trick, a system with the defect is mapped into another system defined on the upper half plane with the boundary. tion at the defect. For example, the boundary condition for the energy-momentum tensor, which implies the energy conservation at the defect, gives the so-called Virasoro gluing condition:

L tot n -L tot -n |B = 0. (2.5)
Here L tot n is the sum of Virasoro generators of CFT 1,2 :

L tot n = L 1 n + L 2 n .
(

The Virasoro gluing condition also ensures that the junction preserves the conformal symmetry. 2The second is the R-matrix, the 2 by 2 matrix defined as [2]

R ij = 0|L i 2 L j 2 |B 0|B , i,j = 1, 2, (2.7)
where |0 is the conformal vacuum. Although the R-matrix has four components, it has only one degree of freedom due to the following three constraints. The first constraint is given by the Virasoro gluing condition:

0|L tot 2 L tot 2 |B = 0|L tot 2 L tot -2 |B = c 1 + c 2 2 0|B , ( 2.8)
where c 1,2 are the central charges for CFT 1,2 , respectively. The second and the third constraints originate from the existence of two primary fields with respect to the total energy-momentum tensor T tot = T 1 + T 2 and its Hermitian conjugate:

W = c 2 T 1 -c 1 T 2 and W = c 2 T 1 -c 1 T 2 .
Thus we have

0|L tot 2 W 2 |B = 0|W 2 L tot 2 |B = 0. (2.9)
We remark that these constraints show that R ij is symmetric:

0 = 0| L tot 2 W 2 -W 2 L tot 2 |B = -(c 1 + c 2 ) 0| L 1 2 L 2 2 -L 2 2 L 1 2 |B . (2.10)
As a result, the R-matrix is parametrized by a single real parameter

ω B = 2 c 1 c 2 (c 1 + c 2 ) 0|W 2 W 2 |B 0|B , ( 2.11)
as

R = c 1 c 2 2(c 1 + c 2 ) c 1 c 2 1 1 c 2 c 1 + ω B 1 -1 -1 1 . (2.12)
Now we give the definition of the reflection/transmission coefficient R/T . The proposal for R and

T is [2] R = 2 c 1 + c 2 R 11 + R 22 , ( 2.13
)

T = 2 c 1 + c 2 R 12 + R 21 . (2.14)
It is easy to show that the sum is given by R + T = 1 for any ω B , which means the energy conservation. Because the R-matrix is written in terms of Virasoro generators, we suggest that R and T are the reflection and transmission coefficients for the energy transport at the defect. We shall see that this interpretation is consistent with our definition of the current reflection/transmission coefficient.

Current reflection and transmission

We generalize the above construction of R and T to the reflection/transmission coefficient for a conserved current with h = 1. When we define the energy reflection/transmission coefficient, there are two key ingredients: the boundary state and the R-matrix. In addition, there are three constraints, which originated from the total energy-momentum tensor T tot and the primary fields W and W , play an important role in counting the effective degrees of freedom of the R-matrix.

Here we shall take the similar process.

We assume that CFT 1,2 have the same symmetry subalgebra C, which is preserved at the conformal defect. For such a defect, we choose the following current gluing condition

j tot,a n + j tot,a -n |B = 0, (2.15)
where j tot,a n = j 1,a n + j 2,a n takes values in the Kac-Moody algebra Ĉ. (Here j a n is the Fourier mode of J a .) Notice that the signs in front of the anti-holomorphic sectors are opposite between energy and current gluing conditions due to the different parity of their conformal weights [START_REF] Cardy | Boundary conditions, fusion rules and the Verlinde formula[END_REF].

The straightforward generalization of the R-matrix is

R[C] ij,ab = - 0|j i,a 1 j j,b 1 |B 0|B . (2.16)
The extra minus sign is due to the sign difference in the gluing conditions. Note that since the gluing condition becomes rather complicated in terms of j 1,a n and j 2,a n , this R-matrix gives a nontrivial value, as we will show later. Here we take the n = 1 component of j i,a n in contrast to L i 2 . In fact, any positive choice of n gives the same R-matrix. To see this fact, let us consider the following equation derived from the Virasoro gluing condition:

0 = 0|j i,a n j j,b n+1 L tot 1 -L tot -1 |B . (2.17)
Together with the commutator [L i m , j i,a n ] = -nj i,a m+n , this leads to the recursion relation

0 = n 0|j i,a n+1 j j,b n+1 |B -(n + 1) 0|j i,a n j j,b n |B . (2.18)
This relation implies that if we defined the R-matrix with mode n, the matrix element 0|j i,a n j j,d n |B could be written in terms of (2.16). In addition, due to the symmetry, we have

R[C] ij,ab = - 0|Gj i,a 1 j j,b 1 G -1 |B 0|B , ( 2.19)
where G = exp{α a (j tot,a 0 + j tot,a 0 )}. If C is a simple Lie algebra, this symmetry factorizes the R-matrix:

R[C] ij,ab = d ab R[C] ij .
(2.20)

We remark that although the R-matrix can be defined with a generic algebra rather than the common subalgebra C, the contribution only from C gives a non-trivial value. 3Now let us see that there are three constraints which reduce the degrees of freedom of the R-matrix. The first constraint is associated with the current gluing condition. Eq. (2.15) leads to

0|j tot,a 1 j tot,b 1 |B = -(k 1 + k 2 )d ab 0|B . (2.21)
This constraint is similar to the constraint (2.8), which is given by the Virasoro gluing condition.

To find the other two constraints, we introduce primary fields with respect to the total current J tot = J 1 + J 2 (and its conjugate J tot ):

K a (z) = k 2 J 1,a (z) -k 1 J 2,a (z), K a (z) = k 2 J 1,a (z) -k 1 J 2,a (z). (2.22)
It is easy to show that these satisfy

0|K a 1 j tot,b 1 |B = 0|j tot,a 1 K b 1 |B = 0. (2.23)
Interestingly, these constraints ensure that R[C] ij is symmetric. In fact, we have

0 = 0|K a 1 j tot,b 1 |B -0|j tot,a 1 K b 1 |B = (k 1 + k 2 ) 0| j 1,a 1 j 2,b 1 -j 2,a 1 j 1,b 1 |B . ( 2
d ab ω B [C] = - 1 k 1 k 2 (k 1 + k 2 ) 0|K a 1 K b 1 |B 0|B . (2.25) With this ω B [C], the R-matrix R[C] ij is given by R[C] = k 1 k 2 k 1 + k 2 k 1 k 2 1 1 k 2 k 1 + ω B [C] 1 -1 -1 1 . (2.26)
Obviously, this expression is similar to (2.12). The level k i plays essentially the same role to the central charge.

Now we can define the reflection and transmission coefficients: R[C] and T [C]

.

R[C] = 1 k 1 + k 2 R 11 + R 22 = 1 (k 1 + k 2 ) 2 k 2 1 + k 2 2 + 2k 1 k 2 ω B [C] ,
(2.27)

T [C] = 1 k 1 + k 2 R 12 + R 21 = 2k 1 k 2 (k 1 + k 2 ) 2 1 -ω B [C] .
(2.28)

From (2.26), it is easy to show that R + T = 1, which ensures the current conservation. We remark that the identification of R/T as the reflection/transmission coefficient is available provided that both of R and T are nonnegative. Although it is unclear that the nonnegative condition holds in general, we shall see that it holds for all examples considered in the present paper. Before ending this section, let us comment on the case with C = su(2) for later use. In this case, the Cartan-Killing form is d ab = -δ ab /2. By defining J ± = J 1 ± iJ 2 , the R-matrix (2.20) can be rewritten as

R[C] ij = -R[C] ij,-+ = 0|j i,- 1 j j,+ 1 |B 0|B , ( 2.29)
as well as ω B [C]:

ω B [C] = 1 k 1 k 2 (k 1 + k 2 ) 0|K - 1 K + 1 |B 0|B , ( 2.30)
where we have used d -+ = -1.

Application to some models

We evaluate reflection and transmission coefficients for conserved currents by using the above definition. In Section 3.1, we consider the simpler case with the permutation boundary condition, where we know the explicit form of the boundary conditions for currents. On the other hand, in Section 3.2, we study the case where SU [START_REF] Quella | Reflection and transmission for conformal defects[END_REF] 2) k 1 +k 2 thanks to the non-trivial interaction at the boundary.

k 1 × SU(2) k 2 is broken into SU(

Permutation boundary condition for a sub-symmetry

Let us first consider the simpler example where we impose the following boundary condition:

J 1,α 1 (z) = J 1,α 1 (z), J 2,α 2 (z) = J 2,α 2 (z), J 1,a (z) = J 2,a (z), J 2,a (z) = J 1,a (z), ( 3.1)
where α 1,2 and a stand for the labels for A 1,2 /C and C respectively. To be consistent with the boundary condition, we have to impose k 1 = k 2 ≡ k c . In this example, degrees of freedom associated with C completely penetrate the defect, while the others are completely reflected. This observation suggests T [C] = 1. Let us show this as follows.

Using the boundary condition, the off-diagonal elements of the R-matrix are This is because only the fields associated with C contribute to the transmission. In other words, we found that among the total degrees of freedom c 1 + c 2 , 2c degrees of freedom completely penetrate and the others are completely reflected. (The factor 2 of 2c stems from the fact that both j 1,a and j 2,a contribute to the energy transport.) This argument supports our identification of T (2.14) as the total energy transmission coefficient. The benefit of our current transmission is that we can see more microscopic information about the transmission process.

0|j 1,a 1 j 2,b 1 |B = 0|j 2,a 1 j 1,b 1 |B = -d ab k c 0|B . ( 3

SU(2)

k 1 × SU(2) k 2 → SU(2) k 1 +k 2
Let us consider the more general case where

A 1,2 = su(2) k 1,2 and C = su(2) k 1 +k 2 .
The symmetry can be rewritten as [START_REF] Quella | Symmetry breaking boundary states and defect lines[END_REF]:

SU(2) k 1 × SU(2) k 2 = SU(2) k 1 × SU(2) k 2 SU(2) k 1 +k 2 × SU(2) k 1 +k 2 . ( 3
i = 0, 1, • • • , k i and 2ρ = 0, 1, • • • , k 1 + k 2 with the identification (ρ 1 , ρ 2 , ρ) ∼ ( k 1 2 -ρ 1 , k 2 2 -ρ 2 , k 1 +k 2 2 -ρ)
B(ρ 1 , ρ 2 , ρ) = μ 1 +μ 2 +μ∈Z S (k 1 +k 2 ) ρμ S (k 1 ) ρ 1 μ 1 S (k 2 ) ρ 2 μ 2 S (k 1 +k 2 ) 0μ S (k 1 ) 0μ 1 S (k 2 ) 0μ 2 (μ 1 , μ 2 , μ) ⊗ |μ , ( 3.4)
with 2μ i ∈ {0, 1, • • • , k i } and 2μ ∈ {0, 1, • • • , k 1 + k 2 }. Here |(μ 1 , μ 2 ,
S (k) ρμ = 2 k + 2 sin π k + 2 (2ρ + 1)(2μ + 1) . (3.5)
Because J tot,a = J H,a , the above boundary state satisfies the current gluing condition (2.15). In order to compute the R-matrix, we have to deal with 0|j i,a 1 j j,b

1 |B , whose non-trivial part is reduced to ω B [C] as shown in (2.26). Since |B = |B(ρ 1 , ρ 2 , ρ) is spanned by the Hilbert space basis for G/H ⊗ H , we first need to expand j i,a -1 j j,b

-1 |0 or K + -1 K - -1 |0
with them as (3.4), and then identify the highest weight vectors with respect to G/H ⊗ H .

To begin with, the ground state |0 is mapped to the tensor product of the ground states:

|0 G = (0, 0, 0) ⊗ |0 H . (3.6)
Notice that |0 G in the left hand side is the ground state for G, while |0 H in the right hand side is that for H . To be more specific, let us focus on the holomorphic sector and consider j i,+ -1 |0 . There should be two independent states corresponding to i = 1, 2. The first one can be easily found,

1 √ k 1 + k 2 j tot,+ -1 |0 G = 1 √ k 1 + k 2 (0, 0, 0) ⊗ j H,+ -1 |0 H ≡ |w 1 . (3.7)
Here we normalized the state: |w 1 2 = 1. Another state that is orthogonal to |w 1 is

|w 2 ≡ 1 √ k 1 k 2 (k 1 + k 2 ) K + -1 |0 G . (3.8)
Due to the commutation relation [K a m , j tot,b n ] = f ab c K c m+n , we find that |w 2 is the current primary state with respect to H . Because |w 2 is killed when j tot,- 0 acts three times, it belongs to a spin-1 representation. Therefore, the H -part of |w 2 is determined:

|w 2 = |w G/H ⊗ |1 H .
(3.9)

In order to find |w G/H , we shall investigate

L G/H 1 . Because |1 H is a primary state of H , L G/H 1 |w 2 = L G 1 -L H 1 |w 2 = L G 1 |w 2 ∝ L 1 1 + L 2 1 K + -1 |0 G = 0. (3.10)
In the last equality, we have used [L i m , j i,a n ] = -nj i,a m+n . Thus |w G/H is a primary state of G/H . Since the conformal weight of |w 2 is 1, the primary state of G/H is uniquely determined:

|w 2 = (0, 0, 1) ⊗ |1 H . (3.11)
Here, we normalized the states: |(0, 0, 1) 2 = |1 H 2 = 1. According to [START_REF] Ishibashi | The boundary and crosscap states in conformal field theories[END_REF], Ishibashi states are expressed as

(0, 0, 0) ⊗ |0 H = |0 ⊗ | 0 + |w 1 ⊗ | Uw 1 + • • • , (0, 0, 1) ⊗ |1 H = |w 2 ⊗ | Uw 2 + • • • , (3.12)
where tildes stand for the anti-holomorphic parts. Dots involve states with higher weights and the current descendant states such as j H,- 0 |1 H . U is an antiunitary operator that acts on H :

Uj H,+ n U -1 = j H,- n , Uj H,3 n U -1 = j H,3 n . (3.13)
By substituting (3.12) into (3.4), we obtain

B(ρ 1 , ρ 2 , ρ) = S (k 1 ) ρ 1 0 S (k 2 ) ρ 2 0 S (k 1 ) 00 S (k 2 ) 00 S (k 1 +k 2 ) ρ0 S (k 1 +k 2 ) 00 (0, 0, 0) ⊗ |0 + S (k 1 +k 2 ) ρ1 S (k 1 +k 2 ) 01 (0, 0, 1) ⊗ |1 + • • • = S (k 1 ) ρ 1 0 S (k 2 ) ρ 2 0 S (k 1 ) 00 S (k 2 ) 00 S (k 1 +k 2 ) ρ0 S (k 1 +k 2 ) 00 |0 + |w 1 ⊗ | Uw 1 + S (k 1 +k 2 ) 00 S (k 1 +k 2 ) ρ1 S (k 1 +k 2 ) ρ0 S (k 1 +k 2 ) 01 |w 2 ⊗ | Uw 2 + • • • , ( 3.14)
where |0 in the second line stands for |0 ⊗ | 0 . The dots in the second line represent the states with higher weights as well as the descendants. Now we proceed to the computation of the R-matrix. Using (2.30), ω B is

ω B su(2) = 1 k 1 k 2 (k 1 + k 2 ) 0|K - 1 K + 1 |B 0|B = w 2 | ⊗ Uw 2 |B 0|B = S (k 1 +k 2 ) 00 S (k 1 +k 2 ) ρ1 S (k 1 +k 2 ) ρ0 S (k 1 +k 2 ) 01 . ( 3.15)
By substituting this into (2.28), the transmission coefficient is obtained as

T su(2) = 2k 1 k 2 (k 1 + k 2 ) 2 1 - S (k 1 +k 2 ) 00 S (k 1 +k 2 ) ρ1 S (k 1 +k 2 ) ρ0 S (k 1 +k 2 ) 01 . ( 3.16)
Notice that T is independent of ρ 1,2 as in the case of the energy transmission [START_REF] Quella | Reflection and transmission for conformal defects[END_REF]. In the case with k 1 = k 2 = 1, corresponding to the junction of s = 1 2 Heisenberg spin chains, this transmission coefficient only gives 0 or 1. This is consistent with the fact that there are only full reflection and full transmission fixed points [START_REF] Eggert | Magnetic impurities in half integer spin Heisenberg antiferromagnetic chains[END_REF]. Another property of T is that T = 0 when ρ = 0. We can explain this property as follows. It was found [START_REF] Quella | Symmetry breaking boundary states and defect lines[END_REF] that for ρ = 0 the original symmetry G = SU(2) k 1 × SU(2) k 2 is restored and the boundary state can be written as

B(ρ 1 , ρ 2 , 0) = |ρ 1 ⊗ |ρ 2 , ( 3.17)
where |ρ i is Cardy's boundary state [START_REF] Cardy | Boundary conditions, fusion rules and the Verlinde formula[END_REF] for CFT i :

|ρ i = μ i S (k i ) ρ i μ i S (k i ) ρ i 0 |μ i , (3.18)
with 2μ i ∈ {0, 1, • • • , k i }.
The right hand side of (3.17) immediately leads to the current gluing conditions for both j 1,a and j 2,a . Thus we obtain R 12 = R 21 = 0, and hence T = 0. The full reflection, or T = 0, implies that the conformal defect is decoupled from the bulk system at the critical point.

Boundary entropy

In this section, we focus on the conformal defect as the impurity in the one-dimensional quantum system. In general, the current in the bulk theory interacts with the impurity as (2.4), and thus this impurity contributes to the total free energy of the system. This means that there is also the impurity contribution to the thermodynamic entropy. This impurity entropy, also called boundary entropy [START_REF] Affleck | Universal noninteger 'ground state degeneracy' in critical quantum systems[END_REF], can be detected, for example, by estimating the entanglement entropy [START_REF] Calabrese | Entanglement entropy and quantum field theory[END_REF]. See also [START_REF] Affleck | Entanglement entropy in quantum impurity systems and systems with boundaries[END_REF].

In order to define the boundary entropy, let us set the total length of the system 2L and the temperature T by compactifying the time direction. Under this condition, the boundary entropy is defined as

S bdry = lim L→∞ S(L, T ) -S 0 (L, T ) , ( 4.1)
where S 0 (L, T ) is the bulk entropy which is obtained in the absence of the impurity. We are especially interested in the zero temperature limit T → 0. In this case it is enough to consider the ground state contribution. If the boundary has no interaction with the bulk, the boundary entropy at T = 0 must be given by the degeneracy of the boundary ground state. For example, if the non-interacting impurity belongs to the spin s representation of SU(2), we have S bdry = ln(2s + 1). On the other hand, when there exists an interaction between the impurity and the bulk, that interaction leads to non-trivial entropy in general.

Let us compute the boundary entropy for the models considered in Section 3.2. It was shown that the boundary entropy is given by the overlap between the boundary state and the conformal vacuum [START_REF] Affleck | Universal noninteger 'ground state degeneracy' in critical quantum systems[END_REF]:

S bdry = ln 0|B -ln 0|B 0 . (4.2)
Here |B 0 represents the situation in the absence of the interaction between the impurity and the bulk [START_REF] Affleck | Universal noninteger 'ground state degeneracy' in critical quantum systems[END_REF][START_REF] Affleck | Quantum impurity problems in condensed matter physics[END_REF][START_REF] Affleck | Conformal field theory approach to the Kondo effect[END_REF]:

|B 0 = |0 ⊗ |0 , ( 4.3)
where |0 's are Cardy's boundary states (3.18) with ρ i = 0. Therefore, we demand that the contribution from |B 0 corresponds to the bulk contribution S 0 . Through (3.17), we can rewrite |B 0 as

|B 0 = B(0, 0, 0) . (4.4)
From the expression (3.14) the overlap between the vacuum and the boundary state is given by 0

B(ρ 1 , ρ 2 , ρ) = S (k 1 ) ρ 1 0 S (k 2 ) ρ 2 0 S (k 1 ) 00 S (k 2 ) 00 S (k 1 +k 2 ) ρ0 S (k 1 +k 2 ) 00 . (4.5)
With the above identification of |B 0 , we have

W bdry ≡ exp(S bdry ) = S (k 1 ) ρ 1 0 S (k 2 ) ρ 2 0 S (k 1 +k 2 ) ρ0 S (k 1 ) 00 S (k 2 ) 00 S (k 1 +k 2 ) 00 . ( 4.6)
Here W bdry stands for the degeneracy of the ground state. Interestingly, this depends on ρ 1,2 in contrast to the reflection/transmission coefficients. As with the Kondo problem, we encounter non-integer degeneracies for generic (ρ 1 , ρ 2 , ρ), which are indications of non-Fermi liquid behavior, and some of them may be related to Majorana-like excitation [START_REF] Emery | Mapping of the two-channel Kondo problem to a resonant-level model[END_REF][START_REF] Béri | Topological Kondo effect with Majorana fermions[END_REF][START_REF] Tsvelik | Majorana fermion realization of a two-channel Kondo effect in a junction of three quantum Ising chains[END_REF][START_REF] Béri | Majorana-Klein hybridization in topological superconductor junctions[END_REF][START_REF] Altland | Majorana spin dynamics in the topological Kondo effect[END_REF]. Since the boundary entropy can be detected in the entanglement entropy [START_REF] Calabrese | Entanglement entropy and quantum field theory[END_REF], it can be a convenient criterion for such a behavior, e.g., in numerical analysis.

In addition to the non-integer degeneracies as discussed above, we also encounter integer ones for some (ρ 1 , ρ 2 , ρ). A remarkable example is W bdry = 2 for ρ 1 = ρ 2 = ρ = 1 with k 1 = k 2 = 2 that has the same symmetry as the two-channel Kondo model. It is known that the two-channel Kondo model usually gives a non-integer degeneracy. However this example indicates that the ground state of the Kondo impurity can have an integer degeneracy when the interaction involves the channel current in addition to the electron spin current. To well understand the origins of these integer degeneracies as well as the physical meaning of ρ's, further investigation is necessary.

The result obtained here provides an interesting implication also for the spin chain models. The situation we have discussed corresponds to the junction of SU(2) chains with arbitrary spins s 1,2 = k 1,2 /2. Thus the expression (4.6) gives a quite general formula for the impurity entropy of the spin chain junction. It is interesting to check that the formula (4.6) can be obtained from the spin chain models by using another analytical method, e.g., Bethe ansatz.

Summary and discussion

We have defined the reflection/transmission coefficient for the conserved current at conformal defects. The BCFT approach offers an analytic and exact method to describe the reflection/transmission process. In addition, our definition provides a microscopic description of the reflection/transmission process. Namely, it reveals which and how much the current penetrates the defect. We have also computed the boundary entropy and observed a non-integer degeneracy.

We add some comments on the Kondo problem, to which our analysis is directly applicable. In particular, for k 1 = k 2 = 2, the model considered in Section 3.2 has the same symmetry as the two-channel Kondo model. In this case the two SU(2) 2 's in SU(2) 2 × SU(2) 2 have different meanings: the first one is for the spin and the second is for the channel. Hence the transmission process means exchanging of spin and channel currents at the defect. As in the case of Kondo impurities, it is interesting to compute the specific heat and the resistivity. That computation could give further information in order to understand the physical meaning of (ρ 1,2 , ρ).

Let us comment on some possibilities beyond this work. It is interesting to extend our analysis of SU(2) k 1 × SU(2) k 2 into SU(N ) k 1 × SU(N ) k 2 . This generalization attracts attention from not only theoretical, but also experimental point of view. It is because such a situation could be realized experimentally with, e.g., a quantum dot [START_REF] Cronenwett | A tunable Kondo effect in quantum dots[END_REF][START_REF] Goldhaber-Gordon | Kondo effect in a single-electron transistor[END_REF][START_REF] Schmid | A quantum dot in the limit of strong coupling to reservoirs[END_REF], or an ultracold atomic system [START_REF] Gorshkov | Two-orbital SU(N ) magnetism with ultracold alkaline-earth atoms[END_REF][START_REF] Desalvo | Degenerate Fermi gas of 87 Sr[END_REF][START_REF] Fukuhara | Degenerate Fermi gases of ytterbium[END_REF][START_REF] Taie | Realization of a SU(2) × SU(6) system of fermions in a cold atomic gas[END_REF][START_REF] Taie | An SU(6) Mott insulator of an atomic Fermi gas realized by largespin Pomeranchuk cooling[END_REF]. Although the Kac-Moody algebra is more complicated for N > 2, one can use the formal expression of boundary states given in [START_REF] Quella | Symmetry breaking boundary states and defect lines[END_REF], and we can compute the R-matrix defined in (2.16) as in the case of the SU(2) theory in principle. The SU(N ) theory may give richer results corresponding to the non-trivial fixed points since its representation theory is rather complicated, although some of the fixed points can be unstable. In addition, if we could take the large N limit, it is interesting to compare with the holographic methods for BCFT [START_REF] Azeyanagi | Holographic calculation of boundary entropy[END_REF][START_REF] Takayanagi | Holographic dual of BCFT[END_REF] and for the Kondo problem [START_REF] Erdmenger | A holographic model of the Kondo effect[END_REF]. Furthermore, by applying the folding trick a number of times, we can straightforwardly generalize our analysis to the multiple junction of CFTs. In this case, the R-matrix becomes M × M matrix with the M multiplicity of the junction. On top of that, it turns out that the level-rank duality allows us to regard this system as the multi-channel Kondo model. We are preparing a paper in this direction.

Although we have focused on the impurity preserving the SU(2) symmetry, we can also consider the situation where SU( 2) is partly broken to U [START_REF] Affleck | Quantum impurity problems in condensed matter physics[END_REF]. Such a situation could be applicable to spin transport, which is driven by the spin-orbit interaction. Since the spin-orbit interaction breaks SU(2) spin symmetry, the non-SU(2) symmetric, or non-magnetic impurity plays an important role in the spin transport at the junction, especially with the Rashba effect induced at the surface. In this way we expect that our transport coefficients can be experimentally observed.

Another challenging issue is to connect critical phenomena including conformal defects to string field theory. String field theory derives non-trivial boundary states from its solutions through the proposed formulas [START_REF] Kudrna | Boundary state from Ellwood invariants[END_REF][START_REF] Kiermaier | The boundary state from open string fields[END_REF]. Therefore, a new boundary state could be presented by string field theory to describe a non-trivial reflection/transmission process. For this purpose, the level truncation technique demonstrated in [START_REF] Michishita | Tachyon lump solutions of bosonic D-branes on SU(2) group manifolds in cubic string field theory[END_REF][START_REF] Kudrna | Ising model conformal boundary conditions from open string field theory[END_REF] may be helpful. In addition, it is interesting to find the interpretation of reflection/transmission coefficient from string theory point of view.

. 24 )

 24 Because of the above three constraints, R[C] ij has only one degree of freedom. Now let us define ω B [C] as

. 2 )

 2 This and (2.26) immediately show that ω B = -1, R 11 = R 22 = 0, and R 12 = R 21 = k c . This proves the full transmission: T [C] = 1. This result is in contrast to the energy transmission coefficient T = 2c/(c 1 + c 2 ) [2] where c 1,2 and c are the central charges associated with A 1,2 and C.

Here we omit the anti-holomorphic part.

Beside, in string theory context, this condition ensures that the energy flow vanishes at the open string endpoints.

We can show that the reflection coefficient (2.28) gives R = 1 for A 1,2 /C, and thus it implies the full reflection process.

Acknowledgements

We would like to thank S.C. Furuya and M. Schnabl for reading the manuscript and giving useful comments. We are also grateful to T. Procházka for valuable discussions. The work of TK is supported in part by Grant-in-Aid for JSPS Fellows (#25-4302). The research of MM was supported by grant GACR P201/12/G028.


Brice Boyer
email: bbboyer@ncsu.edu

Jean-Guillaume Dumas
email: jean-guillaume.dumas@imag.fr

Pascal Giorgi
email: pascal.giorgi@lirmm.fr

Clément Pernet
email: clement.pernet@imag.fr

B David Saunders
email: saunders@udel.edu

Elements of Design for Containers and Solutions in the LinBox library Extended abstract

Keywords: LinBox, design pattern, algorithms and containers, benchmarking, matrix multiplication algorithms, exact linear algebra

We describe in this paper new design techniques used in the C++ exact linear algebra library LinBox, intended to make the library safer and easier to use, while keeping it generic and efficient. First, we review the new simplified structure for containers, based on our founding scope allocation model. We explain design choices and their impact on coding: unification of our matrix classes, clearer model for matrices and submatrices, etc. Then we present a variation of the strategy design pattern that is comprised of a controller-plugin system: the controller (solution) chooses among plug-ins (algorithms) that always call back the controllers for subtasks. We give examples using the solution mul. Finally we present a benchmark architecture that serves two purposes: Providing the user with easier ways to produce graphs; Creating a framework for automatically tuning the library and supporting regression testing.

Introduction

This article follows several papers and memoirs concerning LinBox1 (cf. [START_REF] Boyer | Multiplication matricielle efficace et conception logicielle pour la bibliothèque de calcul exact LinBox[END_REF][START_REF] Dumas | LinBox: A generic library for exact linear algebra[END_REF][START_REF] Dumas | LinBox founding scope allocation, parallel building blocks, and separate compilation[END_REF][START_REF] Giorgi | Arithmétique et algorithmique en algèbre linéaire exacte pour la bibliothèque LinBox[END_REF][START_REF] Turner | Blackbox linear algebra with the LinBox library[END_REF]) and builds upon them. LinBox is a C++ template library for fast and exact linear algebra, designed with generality and efficiency in mind. The LinBox library is under constant evolution, driven by new problems and algorithms, by new computing paradigms, new compilers and architectures. This poses many challenges: we are incrementally updating the design of the library towards a 2.0 release. The evolution is also motivated by developing a high-performance mathematical library available for researchers and engineers that is easy to use and help produce quality reliable results and quality research papers.

Let us start from a basic consideration: we show in the Table 1 the increase in the "lines of code" size2 of LinBox and its coevolved dependencies Givaro and Fflas-Ffpack3 . This increase affects the library in several ways. First demands a stricter development model, and we are going to list some techniques we used. For instance, we have transformed Fflas-Ffpack (cf. [START_REF] Dumas | Dense linear algebra over word-size prime fields: the Fflas and Ffpack packages[END_REF]) into a new standalone header library, resulting in more visibility for the Fflas-Ffpack project and also in better structure and maintainability of the library. A larger template library is harder to manage. There is more difficulty to trace, debug, and write new code. Techniques employed for easier development include reducing compile times, enforcing stricter warnings and checks, supporting more compilers and architectures, simplifying and automating version number changes, automating memory leak checks, and setting up buildbots to check the code frequently. This size increase also requires more efforts to make the library user friendly. For instance, we have: Developed scripts that install automatically the latest stable/development versions of the trio, resolving version dependencies; Eased the discovery of Blas/Lapack libraries; Simplified and sped up the checking process, covering more of the library; Updated the documentation and distinguished user and developer oriented docs; Added comprehensive benchmarking tools.

Developing generic high performance libraries is difficult. We can find a large literature on coding standards and software design references in (cf. [START_REF] Alexandrescu | Modern C++ design: generic programming and design patterns applied[END_REF][START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF][START_REF] Gregor | Generic programming and high-performance libraries[END_REF][START_REF] Stroustrup | The design and evolution of C++[END_REF][START_REF] Sutter | C++ Coding Standards: 101 Rules, Guidelines, And Best Practices[END_REF]), and draw from many internet sources and experience acquired by/from free software projects. We describe advances in the design of LinBox in the next three sections. We will first describe the new container framework in Section 2, then, in Section 3, the improved matrix multiplication algorithms made by contributing special purpose matrix multiplication plugins, and, finally, we present the new benchmark/optimization architecture (Section 4).

Containers architecture

LinBox is mainly conceived around the RAII (Resource Acquisition Is Initialization, see [START_REF] Stroustrup | The design and evolution of C++[END_REF]) concept with reentrant function. We also follow the founding scope allocation model (or mother model) of [START_REF] Dumas | LinBox founding scope allocation, parallel building blocks, and separate compilation[END_REF] which ensures that the memory used by objects is allocated in the constructor and freed only at its destruction. The management of the memory allocated by an object is exclusively reserved to it.

LinBox uses a variety of container types (representations) for matrix and vectors over fields and rings. The fragmentation of the containers into various matrix and blackbox types has been addressed and simplified. The many different matrix and vector types with different interfaces has been reduced into only two containers: Matrix and Vector.

General Interface for Matrices

First, in order to allow operations on its elements, a container is parameterized by a field object (Listing 1), not the field's element type. This is simpler and more general. Indeed, the field element type can be inferred from a value_type type definition within the field type. Then, the storage type is given by a second template parameter that can use defaults, e.g. dense Blas matrices (stride and leading dimension or increment), or some sparse format. In the founding scope allocation model, we must distinguish containers that own (responsible for dynamically allocated memory) and containers that share memory of another. SubMatrix and SubVector types share the memory; Matrix and Vector own it. All matrix containers share the common BlackBox interface described in the next paragraphs, it accommodates both owner and sharer container types, and defines the minimal methods required for a template BlackBox matrix type:

Input/Output. Our matrix containers all read and write from Matrix Market format 4 which is well established in the numerical linear algebra community and facilitates sharing matrices with other software tools. The MatrixMarket header comment provides space for metadata about the provenance of a matrix and our interest in it. However, because of our many entry domains and matrix representations, extensions are necessary to the MatrixMarket format. For instance, the header comment records the modulus and irreducible polynomial defining the representation of a matrix over GF(p e ). We can further adapt the header to suit our needs, for instance create new file formats that save space (e.g. CSR fashion saves roughly a third space over COO, cf. Harwell-Boeing format). Structured matrices (Toeplitz, Vandermonde, etc.) can have file representations specified.

Apply method. This is essential in the BlackBox interface (Sections 2.2 and 3).

Rebind/Conversions. In addition to the rebind mechanism (convert from one field to the other), we add conversion mechanisms between formats, for instance all sparse matrix formats can convert to/from CSR format: this 'star' mechanism can simplify the code (to the expense of memory usage) and may speed it up when some central formats are well tuned for some task. This is a common minimal interface to all our matrix containers that can be used by all algorithms. This interface provides the basic external functionality of a matrix as a "linear mapping" (black box). This interface is shared by: dense containers (Blas-like,...); permutation containers (compressed Lapack or cycle representation); sparse containers (based on common formats or on STL containers such as map, deque,...); structured containers (Diagonal, Hankel, Butterfly,...); compound containers (Compose, Submatrix,...). Additional functions of a container can be added, and flagged with a trait, for example those that support internal changes as for Gaussian elimination.

The apply method

The apply method (left or right) is arguably the most important feature in the matrix interface and the LinBox library. It performs what a linear application is defined for: apply to a vector (and by extension a block of vectors, i.e. a matrix).

We propose the new interface (Listing 2), where In and Out are vector or matrices, and Side is Tag::Right or Tag::Left, whether the operation y ← A ⊤ x or y ← Ax is performed. We also generalize to the operation y ← αAx + βy. This method is fundamental as it is the building block of the BlackBox algorithms (for instance block-Wiedemann) and as the matrix multiplication, main operation in linear algebra, needs to be extremely efficient (Section 3). The implementation of the apply method can be left to a mul solution, which can include a helper/method argument if the apply parameters are specialized enough.

Improving LinBox matrix multiplication

We propose a design pattern (the closest pattern to our knowledge is the strategy one, see [START_REF] Cung | Adaptive and hybrid algorithms: classification and illustration on triangular system solving[END_REF]Fig 2.]) in Section 3.1 and we show a variety of new algorithms where it is used in the mul solution (Section 3.2).

Plugin structure

We propose in Figure 1 a generalization of the strategy design pattern of [START_REF] Cung | Adaptive and hybrid algorithms: classification and illustration on triangular system solving[END_REF]Fig 2.], where distinct algorithms (modules) can solve the same problem and are combined, recursively, by a controller. The main advantage of our pattern is that the modules always call the controller of a function so that the best version will be chosen at each level. An analogy can be drawn with dynamic systems -once the controller sends a correction to the system, it receives back a new measure that allows for a new correction. For instance, we can write (Figure 2) the standard cascade algorithms (see [START_REF] Dumas | Dense linear algebra over word-size prime fields: the Fflas and Ffpack packages[END_REF]) in that model. Cascade algorithms are used to combine several algorithms that are switched using thresholds, ensuring better efficiency than that of any of the algorithms individually. This method allows for the reuse of modules and ensures efficiency. It is then possible to adapt to the architecture, the available modules, the resources. The only limitation is that the choice of module must be fast. On top of this design, we have Method objects that allow caller selection of preferred algorithms, shortcutting the strategy selection. This infrastructure supports modular code. For instance, Fflas-Ffpack has seen major modularization (addition, scaling, reduction,...) Not only does it enable code to be hardly longer than the corresponding pseudocode listings, [START_REF] Boyer | Memory efficient scheduling of Strassen-Winograd's matrix multiplication algorithm[END_REF], (compared to ≈ 2.5× on some routines before) but it also automatically brings performance, because we can separately improve individual modules and immediately have the benefit throughout the whole library.

New algorithms for the mul solution

New algorithms and techniques improve on matrix multiplication in several ways: reducing memory consumption, reducing runtime, using graphics capa-bilities, generalizing the Blas to integer routines.

Reduced memory. The routine fgemm in Fflas uses by default the classic schedules for the multiplication and the product with accumulation (cf. [START_REF] Boyer | Memory efficient scheduling of Strassen-Winograd's matrix multiplication algorithm[END_REF]), but we also implement the low memory routines therein. The new algorithms are competitive and can reach sizes that were limiting. One difficulty consists in using the memory contained in a submatrix of the original matrix, that one cannot free or reallocate.

Using Bini's approximate formula. In [START_REF] Boyer | Matrix multiplication over wordsize prime fields using Bini's approximate formula[END_REF], we use Bini's approximate matrix multiplication formula to derive a new algorithms that is more efficient that the Strassen-Winograd implementation in fgemm by ≈ 5 -10% on sizes 1500-3000. This is a cascade of Bini's algorithm and Strassen-Winograd algorithm and/or the naïve algorithm (using Blas). The idea is to analyze precisely the error term in the approximate formula and make it vanish.

Integer Blas. In order to provide fast matrix multiplication with multiprecision integers, we rely on multimodular approach through the Chinese remainder theorem. Our approach is to reduce as much as possible to fgemm. Despite, the existence of fast multimodular reduction (resp. reconstruction) algorithm [START_REF] Gathen | Modern Computer Algebra[END_REF], the naïve quadratic approach can be reduced to fgemm which makes it more efficient into practice. Note that providing optimized fast multimodular reduction remains challenging. This code is directly integrated into Fflas.

Polynomial Matrix Multiplication over small prime fields. The situation is similar to integer matrices since one can use evaluation/interpolation techniques through DFT transforms. However, the optimized Fast Fourier Transform of [START_REF] Harvey | Faster arithmetic for number-theoretic transforms[END_REF] makes fast evaluation (resp. interpolation) competitive into practice. We thus rely on this scheme together with fgemm for pointwise matrix multiplications. One can find some benchmark of our code in [START_REF] Giorgi | Online order basis and its impact on block Wiedemann algorithm[END_REF].

Sparse Matrix-Vector Multiplication. For sparse matrices a main issue is that the notion of sparsity is too general vs. the specificity of real world sparse matrices: the algorithms have to adapt to the shape of the sparse matrices. There is a huge literature from numerical linear algebra on SpMV (Sparse Matrix Vector multiplication) and on sparse matrix formats, some of which are becoming standard (COO, CSR, BCSR, SKY,...). In [START_REF] Boyer | Exact sparse matrix-vector multiplication on GPU's and multicore architectures[END_REF] we developed some techniques to improve the SpMV operation in LinBox. Ideas include the separation of the ±1 for removing multiplications, splitting in a sum (HYB for hybrid format) of sparse matrix whose formats are independent and using specific routines. For instance, on Z/pZ with word size p, one can split the matrix ensuring no reduction is needed in the dot product and call Sparse Blas (from Intel MKL or Nvidia cuBLAS for instance) on each matrix. One tradeoff is as usual between available memory, time spent on optimizing vs. time spent on apply, and all the more so because we allow the concurrent storage of the transpose in an optimized fashion, usually yielding huge speedups. This can be decided by ad hoc. optimizers.

Work on parallelizations using OpenCL, OpenMP or XKaapi for dense or sparse matrix multiplication include [START_REF] Boyer | Exact sparse matrix-vector multiplication on GPU's and multicore architectures[END_REF][START_REF] Dumas | Parallel computation of echelon forms[END_REF][START_REF] Wezowicz | Dealing with performance/portability and performance/accuracy trade-offs in heterogeneous computing systems: a case study with matrix multiplication modulo primes[END_REF].

Benchmarking for automated tuning and regression testing

Benchmarking was introduced in LinBox for several reasons. First, It gives the user a convenient way to produce quality graphs with the help of a graphing library like gnuplot5 and provides the LinBox website with automatically updated tables and graphs. Second, it can be used for regression testing. Finally, it will be used for selecting default methods and setting thresholds in installation time autotuning.

Performance evaluation and Automated regression testing

Our plotting mechanism is based on two structures: PlotStyle and PlotData.

The PlotGraph structure uses the style and data to manage the output. We allow plotting in standard image formats, html and L A T E Xtables, but also in raw csv or xml for file exchange, data comparisons and extrapolation. This mechanism can also automatically create benchmarks in LinBox feature matrix (this is a table that describes what solutions we support, on which the fields).

Saving graphs in raw format can also enable automatic regression testing on the buildbots that already checked our code. For some specifically determined matrices (of various shapes and sizes and over several fields), we can accumulate the timings for key solutions such as (rank, det, mul,...) over time. At each new release, when the documentation is updated, we can check any regression on these base cases and automatically update the regression plots.

Automated tuning and method selection

Some of the code in LinBox is already automatically tuned (such as thresholds in fgemm), but we improve on it. Instead of searching for a threshold using fast dichotomous techniques, for instance, we propose to interpolate curves and find the intersection. Using least squares fitting, we may even tolerate outliers (but this is time consuming).

Automatically tuning a library is not only about thresholds, it may also involve method/algorithm selection. Our strategy is the following: a given algorithm is tuned for each Helper (method) it has. Then the solution (that uses these algorithms) is tuned for selecting the best methods. At each stage, defaults are given, but can be overridden by the optimizer. The areas where a method is better are extrapolated from the benchmark curves.

  template < class _Field , class _Storage = denseDefault > class Vector ; Listing 1: Matrix or Vector classes in LinBox.

  template < class _In , class _Out > _Out & apply ( _Out &y , const _In & x , enum Side ) ; Listing 2: Apply methods.

Figure 1 :

 1 Figure 1: Controller/Module design pattern

Algorithm 1 :Algorithm 2 :

 12 Algo: controller Input: A and B, dense, with resp. dimensions n × k and k × n. Input: H Helper Output: C = A × B if min(m, k, n) < H.threshold() then Algo(C,A,B,BaseCase()) ; else Algo(C,A,B,RecursiveCase()) end Algo: recursive module Input: A, B, C as in controller. Input: H, RecursiveCase Helper Output: C = A × B Cut A,B,C in Si, Ti ... Pi = Algo(Si, Ti, H) ...

Figure 2 :

 2 Figure 2: Conception of a recursive controlled algorithm

Table 1 :

 1 , it Evolution of the number of lines of code in LinBox.

	LinBox	1.0.0 † ‡ 1.1.0 † ‡ 1.1.6 ‡ 1.1.7 ‡ 1.2.0 1.2.2 1.3.0 1.4.0
	loc (×1000)	77.3	85.8	93.5	103	108	109	112	135
	Fflas-Ffpack	n/a	n/a	n/a	1.3.3	1.4.0 1.4.3 1.5.0 1.8.0
	loc	-	-	-	11.6	23.9	25.2	25.5	32.1
	Givaro loc	n/a -	n/a -	3.2.16 30.8	3.3.3 33.6	3.4.3 3.5.0 3.6.0 3.8.0 39.4 41.1 41.4 42.8
	total	77.3	85.8	124	137	171	175	179	210

This material is based on work supported in part by the National Science Foundation under Grant CCF-1115772 (Kaltofen) and Grant CCF-1018063 (Saunders)

This material is based on work supported in part by the Agence Nationale pour la Recherche under Grant ANR-11-BS02-013 HPAC (Dumas, Giorgi, Pernet).

See http://www.linalg.org.

Using sloccount, available at http://sourceforge.net/projects/sloccount/.

symbol † when Givaro is included and ‡ when contains Fflas-Ffpack

See http://math.nist.gov/MatrixMarket/.

http://www.gnuplot.info/


Filip Křikava
email: filip.krikava@inria.fr

Philippe Collet
email: philippe.collet@unice.fr

Solving the TTC'14 FIXML Case Study with SIGMA

SIGMA is a family of Scala internal Domain-Specific Languages (DSLs) for model manipulation that provides expressive and efficient API for model consistency checking, model-tomodel and model-to-text transformations. In this paper we describe a SIGMA solution for the Transformation Tool Contest 2014 (TTC'14) FIXML case study, a transformation of FIXML XML format into class definitions in Java, C# and C++. The full case study including all three extensions have been realized and are publicly available on Github and in the SHARE environment.

Introduction

In this paper we describe the solution for the TTC'14 FIXML case study [START_REF] Lano | Case study: FIXML to Java, C\# and C++[END_REF] using the SIGMA internal DSLs [START_REF] Krikava | Manipulating Models Using Internal Domain-Specific Languages[END_REF]. The case study involves text-to-model (T2M), model-to-model (M2M) and modelto-text (M2T) transformations, generating Java, C#, C++ code from a FIXML XML messages. Furthermore, we describe our approach to the three proposed extensions. The complete solution is available on a Github1 as well as in the SHARE 2 environment in the virtual machine image Ubuntu12LTS_TTC14_64bit_SIGMA.vdi.

The solution is developed in SIGMA, a family of Scala3 internal DSLs for model manipulation tasks such as model validation and model transformations. Developed as an open source project hosted on Github 4 , SIGMA is a library that provides a dedicated Scala API allowing to manipulate models using high-level constructs similar to ones found in the external model manipulation DSLs such as ETL [START_REF] Kolovos | The Epsilon Transformation Language[END_REF] or ATL [START_REF] Jouault | Transforming Models with ATL[END_REF]. The intent is to provide an approach that developers can use to implement many of the practical model manipulations within a familiar environment, reduced learning overhead and improved usability.

The solution uses the Eclipse Modeling Framework (EMF) [START_REF] Steinberg | EMF: Eclipse Modeling Framework (2nd Edition)[END_REF], which is a popular metamodeling framework widely used in both academia and industry. It is directly supported by SIGMA, however, other meta-modeling frameworks could be used as well, since SIGMA transformations are technologically agnostic.

Solving the TTC'14 FIXML Case Study with SIGMA The remainder of this document is organized as follows: Section 2 gives a brief overview of SIGMA. Section 3 describes the solution for the case study core problem. Section 4 presents the solutions for the three case study extensions. Section 5 evaluates the solution using the evaluation criteria proposed in the case study, and finally Section 6 concludes the paper.

SIGMA Overview

SIGMA DSLs are embedded in Scala [START_REF] Odersky | An Overview of the Scala Programming Language[END_REF], a statically typed production-ready General-Purpose Language (GPL) that supports both object-oriented and functional styles of programming. Scala uses type inference to combine static type safety with a "look and feel" close to dynamically typed languages. It is interoperable with Java and has been designed to host internal DSLs [START_REF] Chafi | Language virtualization for heterogeneous parallel computing[END_REF]. Furthermore, it is supported by the major integrated development environments.

A typical way of embedding a shallow DSL into Scala is by designing a library that allows one to write fragments of code with domain-specific syntax. These fragments are woven within Scala own syntax so that it appears different [START_REF] Dubochet | Embedded Domain-Specific Languages using Libraries and Dynamic Metaprogramming[END_REF]. Next to Scala flexible syntax (e.g. omitting semicolons and dots in method invocations, infix operator syntax for method calls, etc.), it has a number of features simplifying DSL embedding such as implicit type conversions allowing one to extend existing types with new methods, mixin-class composition (i.e. reusing a partial class definition in a new class) [START_REF] Odersky | An Overview of the Scala Programming Language[END_REF], and lifting static source information with implicit resolutions to customize error messages in terms of the domain-specific extensions using annotations [START_REF] Moors | Scala-virtualized[END_REF]. Figure 1 depicts the general organization of the SIGMA DSLs [START_REF] Krikava | Manipulating Models Using Internal Domain-Specific Languages[END_REF]. The use of EMF models in SIGMA is facilitated by a dedicated support layer that underneath uses the default EMF generated Java classes and the EMF API. This layer provides a convenient model navigation and modification support forming a common infrastructure for the task-specific internal DSLs. While SIGMA targets the EMF platform, other meta-modeling platforms could be used as well. In Section 4.3 we will show how to create a support for a Java class model.

Solution Description

This section describes the solution for the core problem of transforming FIXML messages into Java, C# and C++ source code. As suggested, the solution is realized by systematic model transformations that are broken in the following tasks: (1) XML text to XML model (T2M transformation), (2) XML model to a model of an object oriented language (ObjLang) (M2M transformation), and

(3) ObjLang model to source code (M2T transformation).

Overview

The input for the transformation chain is a file representing an FIXML message in the FIXML 4.4 version defined by the FIXML XML Schema [START_REF] Fixml | FIXML 4.4 Schema Version Guide[END_REF]. The output is the corresponding Java, C# and C++ source codes that represent the data of the given FIXML message. The source concerning the solution to the core problem is located in the ttc14-fixml-base directory.

FIXML XML Message to XML Model (T2M)

The T2M transformation consists in parsing an FIXML XML document and creating an XML that conforms to the XML meta-model as specified in the case study description [START_REF] Lano | Case study: FIXML to Java, C\# and C++[END_REF] (cf. Figure 2). Common Infrastructure. The first step before any SIGMA model manipulation task is to create the common infrastructure for the given model i.e. generate support classes that allows for seamless model navigation and modification using standard Scala expressions. In the case of EMF models, the common infrastructure aligns EMF generated Java classes with Scala. This involves model navigation without "get noise" (e.g. node.getSubnodes becomes node.subnodes), promoting EMF collections to corresponding Scala variants to benefit from convenient first-order logic operations (e.g., map, filter, reduce), and first class constructs for creating and initializing new model elements.

Solving the TTC'14 FIXML Case Study with SIGMA This is addressed by generating extension traits that make EMF model elements interoperable with Scala. These traits implicitly extend all model classes with property accessors without the get prefix and convert EMF collections into the corresponding Scala ones. The conversion only happens at the interface level leaving the underlying data storage unchanged. In the same way, existing Scala types are extended with missing operations (e.g. implies). For example, the following is an excerpt 5 of the trait generated for the XML meta-model: Furthermore, for each class in the meta-model, a Scala trait is generated that allows one to create the class instances in a concise way and also allows the classes to participate in Scala pattern matching constructs.

The GenerateModelSupport class is responsible for generating the common infrastructure for the EMF models used in this solution. It is a Scala executable object that first launches the standard EMF code generator to generate Ecore Java classes which is followed by the SIGMA common infrastructure generator. It is done in the way that the resulting sources go into the src-gen directory instead of the src, so that the generated code is separated from the user written one. This class has to be re-run every time any of the models changes.

Transformation. With the above model navigation and manipulation support, we can implement the actual transformation. Parsing XML is a common task and Scala already provides a solid support that is built into the language (e.g. XML literals). The object FIXMLParser is responsible for the transformation. It tries to parse FIXML message coming from various inputs (e.g., text, file, input stream) and build the corresponding XML model. The actual transformation happens in the parseNodes and parseAttributes methods: On the line 2 we discard any potential PCDATA nodes (e.g. white spaces) and then we simply yield a new XMLNode for xml.Node that has been parsed from XML. Only well-formed documents are considered since the underlying Scala XML library throws parsing exception in cases the input document is not well-formed. Additionally, we check for the presence of <FIXML> tag and provide a simple mechanism to discard FIXML messages that are not in the desired FIXML 4.4 Schema version.

XML Model to ObjLang Model (M2M)

This task involves transforming the XML model created in the previous section into a model of an object oriented language, ObjLang.

ObjLang meta-model. The meta-model of the ObjLang model used in this solution is shown in Figure 3. It originates from the Featherweight Java model [START_REF] Igarashi | Featherweight Java: a minimal core calculus for Java and GJ[END_REF], concretely from the version Figure 3: ObjLang meta-model available at the EMFtext website 6 . It provides a reasonable abstraction over the close yet different models of the concerned programming languages. The model supports basic classes with fields, data types that are organized in a similar fashion as in Ecore (i.e. separating external types from model classes), and a basic set of expressions that is used for field initializations. The model itself more closely resembles a Java model than for example a C++ model. For example, a Field can optionally have an initial value, which is a feature not supported in C++ 7 . These differences are left to be handled by the M2T transformers since the aim is to have just a single language agnostic meta-model.

Transformation. An M2M transformation provides necessary support for translating models into other models, essentially by mapping source model elements into corresponding target model elements. An imperative style of M2M transformation [START_REF] Czarnecki | Feature-based survey of model transformation approaches[END_REF] is already supported thanks to the common infrastructure layer described above. On the other hand, the lower level of abstraction of the imperative transformation style leaves users to manually address issues such as orchestrating the transformation execution and resolving target elements against their source counterparts [START_REF] Kolovos | The Epsilon Transformation Language[END_REF]. Therefore, inspired by ETL and ATL, we provide a dedicated internal DSL that combines the imperative features with declarative rule-based execution scheme into a hybrid M2M transformation language.

In SIGMA a M2M transformation is represented as a Scala class that inherits from the M2MT base class, which itself brings M2M DSL constructs into the class scope. Concretely, the XMLMM2ObjLang class is defined as: Next to extending from the M2MT base class, it also mixes the XMLMM and ObjLang traits which are the generated support for the respective models participating in this transformation. In lines 3 and 4 it further specifies the transformation source and target models. In this case we translate one model into another one, but multiple models are supported.

The transformation rules are specified as methods. For example, the first rule of the transformation is defined as: This method creates a rule named XMLNode2Class that transforms an XMLNode into a Class. A transformation rule in SIGMA may optionally define additional targets, but there is always one primary source to the target relation. This rule represents a matched rule which is automatically applied for all matching elements. When such a rule is executed, the transformation engine first creates all the defined target elements and then calls the method whose body populates their content using arbitrary Scala code. Inside the method body, additional target elements can be constructed (using the support provided by the common infrastructure), but in such a case, the developer is responsible for their proper containment and there will be no trace links associated with them.

A matched rule is applied once and only once for each matching source element, creating a 1:1 or 1:N mapping. However, this is not the case in the current scenario where XML document may contain multiple sibling elements with the same tag name which all should be mapped into an exact same class. This is done by associating all the same-tag siblings to the very same class during the rule application on the first of them (line 2). The method allSameSiblings is a helper method that collects all the elements that have the same tag and are at the same level.

The next four lines (4-7) populates the content of the class. The expression on the line 5

t.members ++= s.sTargets [Constructor] assigns all constructors that can be transformed from the source XML node into the class. Similarly t.members ++= s.allAttributes.sTarget[Field] add fields that have been transformed from the XML node attributes. The two methods sTarget and sTargets are defined on all model elements. They provide a way to relate the corresponding target elements that have been already or can be transformed from source elements. The difference between them is that sTarget should be used in the case of 1:N relationship between the source and target as opposed to 1:1 in the case of sTarget.

As for constructors, they are transformed using the following two rules: The first one denotes a default (zero-argument) constructor. As we have discussed earlier, the ObjLang favors field initialization to constructor initialization and therefore the rule body is almost empty. The single expression is the very same association that ensures that all same-tag sibling nodes maps to the same default constructor.

Unlike the default constructor, the rule creating a non-default constructor should only be applicable in the case there is at least one field to be set. In SIGMA this condition is represented by a rule guard that can further limit rule application using a boolean expression. The !s.isEmptyLeaf checks whether there is at least one attribute or a subnode in any of the same-tag siblings. It then creates a constructor parameter for each of the attributes and subnodes and uses them to initialize the class fields.

The constructor parameters are created using the following two rules, one for XML attribute and one for XML node. The @LazyUnique annotation denotes a lazy unique rule. Such rule is not automatically applied for matching elements and instead it has to be explicitly called using the sTarget or sTargets methods. Unlike lazy rule (annotated by @Lazy), it establishes a transformation trace between the source and targets and therefore it always returns the same targets for a given source. The first one translates an XML attribute into a field. In the core problem specification, only string data types are used and therefore it assigns string data type regardless of the actual value of the attribute. In order not to conflict with language programming keywords, we provide a check that simply prepends the name with an underscore. The name conflicts could also be handled later at the M2T level, where each transformer can include a list of its language keywords. However, this could result in a state in which different names would be used for the same fields making the code inconsistent.

The second rule converts an XML node into a field. It has to handle the case of having a multiple same-tag siblings. The case description proposes to use either multiple fields initialized by specific constructors or by an array/list of such objects. While the former is easier to implement (simply by making the rule lazy), it creates a scalability problem since in Java, there is a limit of the maximum number of method parameters. For example the test case test5.xml already exceeds this number. Therefore we have opted for the latter solution and use arrays to represent multiple same-tag sibling nodes. The number of same-tag sibling nodes can vary within a parent node. For example: <Pty ID="OCC" R="21"/> <Pty ID="C" R="38">  </Pty> <Pty ID="C" R="38" Z="Q">

</Pty>

The Sub should be represented by an array field and the default initialization of PosRpt should equal to the following (in Java):

public Pty[] Pty_objects = new Pty[] { new Pty("OCC", "21", null, new Sub[] { null, null }), new Pty("C", "38", null, new Sub[] { new Sub("ZZZ", "2", null), null }), new Pty("C", "38", "Q", new Sub[] { new Sub("ZZZ", "2", null), new Sub("ZZZ", "3", "X") }) };

Note that the first and second instances of Pty contains two and one null respectively in the place of missing Sub subnode.

The ConstructorCall used for field initializations in the ruleXMLNode2Field is created from an XML node using the last rule in the transformation: First we need to find which constructor shall be used depending whether the given XML node (or any of its same-tag siblings) contains any attributes or subnodes. Next, we need to resolve the arguments for the case of non-default constructor. We do this by using the sources, i.e., the source elements (XML node or XML attribute) that were used to create the constructor parameters. SIGMA provides sSource method that is the inverse of sTarget call with the difference that it will not trigger any rule execution. In the pattern matching we need to cover all possible cases such as an attribute defined locally or an attribute defined in a same-tag sibling, thus using null for its initialization.

ObjLang Model to Source code (M2T)

This task involves transforming the ObjLang model into source code for various programming languages. In the core problem solution, Java, C# and C++ are considered.

M2T transformations translate models into text by mapping source model elements into corre-sponding textual fragments. SIGMA provides a template-based approach whereby string patterns are extended with executable logic for code selection and iterative expansion [START_REF] Czarnecki | Feature-based survey of model transformation approaches[END_REF]. Unlike most of the external DSLs for M2T transformation, SIGMA uses the code-explicit form, i.e., it is the output text instead of the transformation code that is escaped. From our experience, in non-trivial code generations, the quantity of text producing logic usually outweighs the text being produced. For the parts where there is more text than logic we rely on Scala multi-line string literals and string interpolations allowing one to embed variable references and expressions directly into strings. Since we target multiple programming languages at the same time, we organize the code generation in a set of Scala classes and rely on Scala class inheritance and class mix-ins to compose, in a modular way, configuration for the respective languages. In the base class BaseObjLangMTT we define methods that synthesize expressions and data types. The default (Java) implementation can be then easily overwritten by other languages. Next we abstract a class generation into BaseObjLang2Class. The code generation is split into a fine-grained templates, represented as regular Scala methods, that generates fields, constructors and the like: Following the same pattern, a M2T transformation in SIGMA is a Scala class extending from the M2T base class. Line 3 defines the type of model element, i.e., the transformation source. A M2T transformation consists in a set of templates that are represented as methods with the main method as the entry point. From there, a transformation is split and logically organized into smaller templates in order to increase modularity and readability. The most common operation in a M2T transformation is a text output. A convenient way to output text in our DSL is through a unary ! (bang) operator that is provided on strings. The prefix s right before the string double quote denotes an interpolated string, which can include Scala expressions in a type-safe way.

Together with the ObjLang2Java class, a complete ObjLang to Java transformer can be instantiated. The class ObjLang2Java contains the Java language specifics which, in this case, is only the name of the string data type. The generator for the C# is exactly the same and the class ObjLang2CSharp also only defines the string data type.

For C++, the situation is a bit more complicated, since we need to generate two files, a header and an implementation file. Also the C++ syntax differs from the one of Java a bit more. Furthermore, C++ does not support fields initialization and therefore the code generator must generate the correct initialization in the constructor. We use the C++11 standard since it supports inline array creation in the similar way as Java or C#, which greatly simplifies the code generation.

Extensions

In this section we describe our solutions to the case study extensions.

Extension 1 -Selection of Appropriate Data Types

The source concerning this is located in the ttc14-fixml-extension-1 directory.

There are three changes needed in order to implement this extension.

(1) The first one is in the ObjLang meta-model where we need to add new expression classes representing literals for the new data types. In this extension we consider the following new data types: double, long and integer. While this list does not cover all the possible XML Schema data types, it provides a good basis for demonstrating how some support for additional ones could be added.

(1) The second one concerns the M2M transformation. We have to add the necessary support for guessing the data type of an attribute based on the string values of all of the same-tag siblings that have have the attribute in question. Following is the code snippet that realizes it: Java classes in an object oriented model and therefore the actual transformation into ObjLang is actually easier than in the case of the FIXML messages. Finally, the JAXB can be thought of as a another model transformation and therefore our solution is still within the model driven engineering domain.

The new input is a location of the FIXML XSD files and the new transformation workflow consists of the following stages:

(1) XSD to Java sources using JAXB.

(2) Compilation of Java source using regular Java compiler.

(3) Java model to ObjLang transformation. The new transformation is about 30% smaller than the one developed in the first extension and arguably less complex. It also demonstrates SIGMA support for manipulating different models than EMF. The source concerning the extension 3 solution is in the ttc14-fixml-extension-3 directory.

One limitation of the current implementation is that we do not extend the C code generator to support the notion of class inheritance and for abstract classes. A potential solution is described in by Schreiner [START_REF] Schreiner | Object Oriented Programming with ANSI-C. Axel-Tobias Schreiner[END_REF], however it requires to build a lot of supporting infrastructure which is out of the scope of this TTC'14 case. Similarly to the extension 1, we do not handle all the XML schema data types, but only the ones that appear in the FIXML schema.

Evaluation

In this section we evaluate the proposed solution using the evaluation criteria proposed in the case study description [START_REF] Lano | Case study: FIXML to Java, C\# and C++[END_REF]. For the brevity, we only include the evaluation of the core problem solution. However, each extension is represented as a separate project and therefore further evaluation can be derived by comparing the changes required for their respective implementations.

Solving the TTC'14 FIXML Case Study with SIGMA Complexity. The case study description proposes to measure the complexity as the number of operator occurrences, features and entity type name references in the specification expressions.

To the best of our knowledge we do not know about any tool that can provide this metric for Scala code. We can therefore only provide our own estimate which is a rough number since it depends at which depth an expression is considered atomic. The M2M transformation of the core problem solution contains about 450 expressions. It uses 18 meta-models classes with 23 references.

Accuracy. The accuracy measures the syntactical correctness of the generated source code and how well does the code represents the FIXML messages.

The generated code is checked to be compiled for all valid examples provided in the case study. The compilation does not produce any warning and does not require any special compiler settings 9 .

We used array representation of the same-tag sibling nodes which improves the quality of the code in comparison to numbered fields, and also provides better scalability. By implementing the first extension, we have further improved the usefulness of the generated code by guessing the appropriate type (cf. Section 4.1). While we do not cover the complete XML Schema type system, the solution is extensible and adding a support for a new data type is just a matter of providing the correct mapping into the corresponding languages. Finally, we have also implemented the generic FIXML Schema transformation that should result in a complete representation of FIXML messages in the different languages.

The case study did not require to provide additional features such as property getters and setters, or C/C++ destructors. As such the usability of the generated code is rather limited. However, the implementation of these features should be rather straightforward.

Development effort. Providing a correct measure of the complete development effort is not easy since by working on the case study we were also improving SIGMA at the same time. The solution for the code problem generating only Java code took about 4 person-hours in which about half was spent on designing the right ObjLang model by trial-and-error. Extending the code generator facilities for C# was almost for free as it involves only few lines of code. The C++ version was ready in less than one person-hour. The first extension was also finished in less than one hour since the ObjLang meta-model already supported multiple data types. The second extension involved more effort to correctly synthesize C code. Finally, the most work has been spent on the last extensions. In total, the development effort could be estimated to be about 15 person-hours.

Fault tolerance. A high fault tolerance is in cases that the transformation can detect invalid XML input and produce accurate results. In our solution, the well-formedness of the XML document is verified by the underlying Scala XML parser that provides a rather verbose error message indicating at which input location it found errors. Our parser provides additional checks that assert the input document to be a FIXML 4.4 Schema version and not just any well-formed XML document or FIXML DTD version. This check is however rather simple, but could be easily extended by attaching a FIXML XML Schema location so the parser can verify the document correctness. Execution time. The execution time for the transformations of the test data set provided by the case study is shown in Table 1. The times were collected by running the transformations in the SHARE virtualized environment Ubuntu12LTS_TTC14_64bitSI G M A.vdi. Therefore the following measures should be considered as micro-benchmark metrics with all the drawback that micro-benchmarking brings. Modularity. Modularity is defined as 1 -d r , where d is the number of dependencies between rules (implicit or explicit calls, ordering dependencies, inheritance or other forms of control or data dependence) and r is the number of rules [START_REF] Lano | Case study: FIXML to Java, C\# and C++[END_REF].

Message

The XMLMM2ObjLang for the core problem consists of r = 8 rules. There is one top level rule and all the other rules are calls, explicitly making d = 7. The modularity according to the formula is therefore 0.125.

Conclusion

In this paper we have presented a SIGMA solution for the TTC'14 FIXML case study. It covers the core problem of generating Java, C# and C++ code from FIXML messages including solutions for all of the case study extensions. The implementation is based on a systematic transformations of XML: (1) a text-to-model transformation of an XML input into an XML meta-model, (2) a model-to-model transformation of the XML meta-model into a object-oriented language-agnostic meta-model called ObjLang, and finally (3) a model-to-text transformation of ObjLang into a set of source code implementations for Java, C#, C++ and also C (in the second case study extension). We have specially opted for using a non-trivial ObjLang model in order to demonstrate a complex, yet expressive and quite concise transformation. The complete implementation of the core problem consists of 500 lines of Scala code 10 . Moreover, the ObjLang with the M2T generators provides a generic object-oriented language model that could be likely reused in other model driven engineering scenarios.

In the third case study extension, we have implemented a generic FIXML Schema transformation into ObjLang model based on transforming annotated Java classes generated by Java Architecture for XML Binding.

Figure 1 :

 1 Figure 1: Sigma EMF to Scala Support

Figure 2 :

 2 Figure 2: XML meta-model

  trait XMLMM extends EMFScalaSupport { implicit class XMLNode2Sigma(that: XMLNode) { def tag: String = that.getTag def tag_=(value: String): Unit = that.setTag(value) def subnodes: EList[XMLNode] = that.getSubnodes def attributes: EList[XMLAttribute] = that.getAttributes } }

  protected def parseNodes(nodes: Iterable[Node]): Iterable[XMLNode] = { val elems = nodes collect { case e: Elem => e } for (elem <elems) yield XMLNode( tag = elem.label, subnodes = parseNodes(elem.child), attributes = parseAttributes(elem.attributes)) } protected def parseAttributes(metaData: MetaData) = metaData collect { case e: xml.Attribute => XMLAttribute(name = e.key, value = e.value.toString) }

class

  XMLMM2ObjLang extends M2MT with XMLMM with ObjLang { sourceMetaModels = _xmlmm targetMetaModels = _objlang // transformation rules }

  def ruleXMLNode2DefaultConstructor(s: XMLNode, t: Constructor) { s.allSameSiblings foreach (associate(_, t)) } def ruleXMLNode2NonDefaultConstructor(s: XMLNode, t: Constructor) = guardedBy { !s.isEmptyLeaf } transform { s.allSameSiblings foreach (associate(_, t)) for (e <-(s.allAttributes ++ s.allSubnodes.distinctBy(_.tag))) { val param = e.sTarget[Parameter] val field = e.sTarget[Field] t.parameters += param t.initialisations += FieldInitialisiation( field = field, expression = ParameterAccess(parameter = param)) } }

  @LazyUnique def ruleXMLAttribute2ConstructorParameter(s: XMLAttribute, t: Parameter) { t.name = checkName(s.name) t.type_ = s.sTarget[Field].type_ } @LazyUnique def ruleXMLNode2ConstructorParameter(s: XMLNode, t: Parameter) { val field = s.sTarget[Field] t.name = field.name t.many = field.many t.type_ = field.type_ } The class fields are populated from the ruleXMLNode2Class rule (lines 6 and 7). It calls the following two lazy unique rules: @LazyUnique def ruleXMLAttribute2Field(s: XMLAttribute, t: Field) { t.name = checkName(s.name) t.type_ = DTString t.initialValue = StringLiteral(s.value) } @LazyUnique def ruleXMLNode2Field(s: XMLNode, t: Field) { val allSiblings = s.allSameSiblings allSiblings foreach (associate(_, t)) t.type_ = s.sTarget[Class] val groups = (s +: allSiblings) groupBy (_.eContainer) val max = groups.values map (_.size) max if (max > 1) { t.name = s.tag + "_objects" t.many = true val init = ArrayLiteral(type_ = s.sTarget[Class]) val siblings = groups(s.eContainer) init.elements ++= siblings.sTarget[ConstructorCall] init.elements ++= 0 until (max -siblings.size) map (_ => NullLiteral()) t.initialValue = init } else { t.name = s.tag + "_object" t.initialValue = s.sTarget[ConstructorCall] } }

@

  Lazy def ruleXMLNode2ConstructorCall(s: XMLNode, t: ConstructorCall) { val constructor = s.sTargets[Constructor] .find { c => (c.parameters.isEmpty && s.isEmptyLeaf) || (c.parameters.nonEmpty && !s.isEmptyLeaf) constructor.parameters source = param.sSource.get } yield { source match { case attr: XMLAttribute => // we can cast since attributes have always primitive types val dataType = param.type_.asInstanceOf[DataType] s.attributes .find(_.name == attr.name) .map { local => StringLiteral(local.value) } .getOrElse(NullLiteral()) case node: XMLNode => s.subnodes.filter(_.tag == node.tag) match { case Seq() if !param.many => NullLiteral() case Seq(x) if !param.many => x.sTarget[ConstructorCall] case Seq(xs @ _ * ) => val groups = (node +: node.allSameSiblings) groupBy (_.eContainer) val max = groups.values map (_.size) max val init = ArrayLiteral(type_ = param.type_) init.elements ++= xs.sTarget[ConstructorCall] init.elements ++= 0 until (max -xs.size) map (_ => NullLiteral())

  foreach genConstructor def genFields = source.fields foreach genField def genField(c: Field) = !s"public ${type2Code(c)} ${c.name}${toInitCode(c)};" def toInitCode(f: Field) = " = " + (f.initialValue map toCode getOrElse ("")) def genConstructor(c: Constructor) = { val args = c.parameters map param2Code mkString (", ") !s"public ${source.name}($args)" curlyIndent { c.initialisations foreach genFieldInitialization } !endl } def genFieldInitialization(fi: FieldInitialisiation) = !s"this.${fi.field.name} = ${toCode(fi.expression)};" }

trait

  ObjLang2Java extends BaseObjLangMTT { override def class2Code(p: DataType) = "String" }

( 4 )( 5 )

 45 ObjLang to source transformation. The implementation involves following changes: (1) Extending the ObjLang model with a new classifier representing enumerated types. (2) Extending the ObjLang model with the notion of a simple class inheritance. (3) Extending the ObjLang model with the notion of abstract classes. (4) A new M2M transformation between Java class model represented by the Java reflection API and ObjLang model. Extending the M2T transformation to cover the new ObjLang model concepts.

Table 1 :

 1 Execution times for the test FIXML messages as measured on SHARE (in milliseconds)

		T2M M2M M2T Total
	test1	9	70	191	270
	test2	27	351	284	662
	test5	1201	2734	459 4394
	test6	376	1387	393 2156
	Total	1613	4542 1327 7482

https://github.com/fikovnik/ttc14-fixml-sigma

http://is.ieis.tue.nl/staff/pvgorp/share/

http://scala-lang.org/

https://fikovnik.github.io/Sigma

XML meta-model generated code is in the fr.inria.spirals.sigma.ttc14.fixml.xmlmm.support package.

#include <stdlib.h>

https://jaxb.java.net/

The C/C++ -fPIC option is a standard option allowing the object files to be included in libraries, cf. http: //gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options

The extension 1 consists of 550, extension 2 of 720 and extension 3 of 770 source lines of code

Acknowledgment This work is partially supported by the Datalyse project www.datalyse. fr.

Extension 2 -Extension to Additional Languages

This extension adds a support for the C language. Since C is not an object oriented language, more work have to be done in the code generator part. It is important to node, that the M2M or T2M transformations have to remain untouched.

Instead of classes, in the case of the C language, we generate C structs with appropriate functions simulating object constructors. For each ObjLang class we generate a header file with a struct definition, a function for the struct creation and a set of functions representing class constructors. Following is an example of the C code synthesized from this FIXML message (for the Pty node): this->Sub_objects = (Sub ** ) new_array(2, Sub_init_custom(Sub_new(), "2", "ZZZ"), NULL); return this; } In order to simplify the code generator, we use a helper function void ** new_array(int size, ...) that allows us to initialize arrays using simple expressions, which is not directly supported by C language or by the standard C library.

Despite the fact that C is not an object oriented language, our organization of the M2T transformation templates makes the implementation only 36 lines longer (30%) than the C++ version. The source concerning the extension 2 solution is in the ttc14-fixml-extension-2 directory.

Extension 3 -Generic Transformation

The last extension aims at generic transformation between FIXML Schema and ObjLang model. Providing such a generic transformation essentially means creating a generic XML schema to Ob-jLang transformation. Such a task is far from being trivial and it would require a significant engineering effort. Therefore we have decided for an alternative solution in which we transform Java classes generated from an XML schema by the Java Architecture for XML Binding tool 8 .

The advantage of this solution is that the JAXB already does all the hard work of parsing XML schema, resolving the element inheritance, substitutability, data types and others. The model of