Claire Mouton
email: claire.mouton@inria.fr

I V Eigen

V Flens

Gmm++

Linear Algebra Libraries

Part II

CPPLapack

CPPLapack is a C++ class wrapper for Blas and Lapack.

Part I

Requirements

This document has been written to help in the choice of a linear algebra library to be included in Verdandi, a scientific library for data assimilation. The main requirements are 1. Portability: Verdandi should compile on BSD systems, Linux, MacOS, Unix and Windows. Beyond the portability itself, this often ensures that most compilers will accept Verdandi. An obvious consequence is that all dependencies of Verdandi must be portable, especially the linear algebra library.

2. High-level interface: the dependencies should be compatible with the building of the high-level interface (e. g. with SWIG, this implies that headers (.hxx) have to be separated from sources (.cxx)).

3. License: any dependency must have a license compatible with Verdandi licenses (GPL and LGPL).

4. C++ templates, sparse matrices and sparse vectors have to be supported.

Information reported here was collected from December 2008 to March 2009.

Part III

Eigen

Eigen is a C++ template library for linear algebra, part of the KDE project. Eigen Distribution 2.0-beta6 -soon released Doc. updated in Jan. 2009 http://eigen.tuxfamily.org/ in development 7 contributors, 2 developers First release: Dec. 2006 License: LGPL and GPL (GPL compatible) Types of matrices and vectors available -Dense and sparse matrices and vectors -Plain matrices/vectors and abstract expressions -Triangular and diagonal matrices -Column-major (the default) and row-major matrix storage Linear algebra operations available -Triangular, SVD, Cholesky, QR and LU solvers -Eigen values/vectors solver for non-selfadjoint matrices -Hessemberg decomposition -Tridiagonal decomposition of a selfadjoint matrix Interface with other packages For sparse matrices: TAUCS, umfpack, cholmod and SuperLU Performance Very efficient, see benchmark: http://eigen.tuxfamily.org/index.php?title=Benchmark Portability: platforms and compilers supported Standard C++ 98, compatible with any compliant compiler such as -GCC, version 3.3 and newer -MSVC (Visual Studio), 2005 and newer -ICC, recent versions -MinGW, recent versions

Installation

No dependency

Miscellaneous -Templates supported -Todo includes: interface to Lapack and eigensolver in non-selfadjoint case -Examples of users: KDE related projects such as screensavers, kgllib, kglengine2d, solidkreator, painting and image editing Avogadro, an opensource advanced molecular editor VcgLib, C++ template library for the manipulation and processing of triangular and tetrahedral meshes MeshLab, for the processing and editing of unstructured 3D triangular meshes and point cloud The Yujin Robot company uses Eigen for the navigation and arm control of their next generation robots (switched from blitz, ublas and tvmet) Limitations -Sparse matrices and vectors still experimental -Eigen 2 is a beta version (Eigen 1 is the old stable version)

Part IV Flens Flens (Flexible Library for Efficient Numerical Solutions) is a C++ library for scientific computing providing interface for Blas and Lapack. Flens intends to be the building block of choice for the creation of serious scientific software in C++.

Flens Distribution RC1 -Jul. 2007 Doc. updated in Feb. 2008 http://flens.sourceforge.net in development 9 developers First release: 2004 License: BSD License (GPL compatible) Types of matrices and vectors available -General, triangular and symmetric matrix types -Storage formats: full storage (store all elements), band storage (store only diagonals of a banded matrix), packed storage (store only the upper or lower triangular part) -Sparse matrix types: general and symmetric, compressed row storage; random access for initialization Linear algebra operations available -Linear systems solving using QR factorization -Cg and Pcg methods

Interface with other packages

Blas and Lapack

Performance

Installation

Requires Blas, Lapack and CBlas

Miscellaneous

-Extensible: e. g. easy integration of user-defined matrix/vector types -Flexible: e. g. generic programming of numerical algorithms -Flens implements a view concept for vectors and dense matrices: a vector can reference a part of a vector, or also a row, column or diagonal of a matrix; you can apply to these views the same operations as for regular vectors and matrices.

-Templated matrices and vectors with several storage formats

Limitations

Limitations

-No separation between headers and sources (only header files) -No eigenvalues computation for sparse matrices -Gmm++ primary aim is not to be a standalone linear algebra library, but is more aimed at interoperability between several linear algebra packages.

Part VI GNU Scientific Library (GSL) GSL is a numerical library for C and C++ programmers. The library provides a wide range of mathematical routines covering subject areas such as linear algebra, Blas support and eigensystems. GSL Distribution GSL-1.12 -Dec. 2008 Doc. updated

Miscellaneous -Templates supported -Separation between headers and sources

Limitations

-Its main use is in simulation of communication systems and for performing research in the area of communications. It is also used in areas such as machine learning and pattern recognition.

-One important high-performance feature missing in IT++ is the ability to create "submatrix-views" and "shallow copies" of matrices, i.e. pass submatrices by reference -instead of by value (compared to Lapack++).

Part VIII Lapack++

Lapack++ is a library for high performance linear algebra computations. Lapack++ Distribution beta 2.

Miscellaneous

-Thanks to templates, the solvers can be used for any type of matrix and preconditioning, not only Seldon matrices: very useful to perform a matrix-vector product when the matrix is not stored -Provides a Python interface generated by SWIG -Exception handling and several debug levels helpful while coding -Good coverage of the interface to Blas and Lapack routines (see section 4) -A few alternative functions provided in C++ if Blas is not available

Limitations

Trilinos

Trilinos provides algorithms and enabling technologies within an object-oriented software framework for large-scale, complex multi-physics engineering and scientific problems. Trilinos is a collection of interacting independent packages (package names are in italic).

Trilinos

Installation

Requires Blas and Lapack

Miscellaneous -Examples of users: SIERRA (Software Environment for Developing Complex Multiphysics Applications), SALINAS (structural dynamics finite element analysis), MPSalsa (high resolution 3D simulations with an equal emphasis on fluid flow and chemical kinetics modeling), Sundance (finite-element solutions of partial differential equations), DAKOTA (Design Analysis Kit for Optimization and Terascale Applications ; coding for uncertainty quantification, parameter estimation and sensitivity/variance analysis) -Most of Trilinos functionalities available in a Python script -A package of basic structures with templated types (Tpetra, first release distributed with 9.0.1) -EpetraExt enables objects to be easily exported to MATLAB -Trilinos is based on established algorithms at Sandia. The effort required to develop new algorithms and enabling technologies is substantially reduced because a common base provides an excellent starting point. Furthermore, many applications are standardizing on the Trilinos APIs: these applications have access to all Trilinos solver components without any unnecessary interface modifications.

Limitations

-Not yet available: templates (except in an isolated package, Teuchos) and sparse vectors (Tpetra is still under heavy development, release planned in Mar./Apr. 2009) -Impossible to build Trilinos under Windows without Cygwin (improved Windows support in a further release) -Trilinos is a complex collection of interoperable packages and requires some careful configuration (with a suitable set of packages and options) 3.2.3,3.3.x,3.4.x,4.0.x;MSVC 7.1,8. MV++ is a small set of concrete vector and matrix classes specifically designed for high performance numerical computing, including interfaces to the computational kernels found in Blas: http://math.nist.gov/mv++/. Limitations -Only building blocks to a larger-user level library such as SparseLib++ and Lapack++.

Newmat C++ library supports various matrix types. Only one element type (float or double) is supported. The library includes Cholesky decomposition, QR, triangularisation, singular value decomposition and eigenvalues of a symmetric matrix: http://www.robertnz.net/nm_intro.htm. Limitations -No sparse matrices and vectors, templates not supported.

RNM by Frédéric Hecht provides C++ classes for arrays with vectorial operations: http://www.ann.jussieu.fr/ ~hecht/. Limitations -Only general matrices, no sparse matrices, no vectors, only one linear system solver (conjugate gradient), no English documentation.

SL++

(Scientific Library) is a C++ numerical library, composed of modules specialized in various fields of numerical computations: http://ldeniau.home.cern.ch/ldeniau/html/sl++.html. Limitations -Not developed since 1998. TCBI (Temporary Base Class Idiom) templated C++ numerical library implements basic data structures like complex numbers, dynamic vectors, static vectors, different types of matrices like full matrices, band matrices, sparse matrices, etc. It also includes some standard matrix solvers like Gauss-Jordan, LU-decomposition and Singular Value Decomposition and a set of powerful iterative solvers (Krylov subspace methods along with preconditioners). Also interfaces to netlib libraries such as CLapack or SuperLU. Its specificity is being exclusively written in C++, without needing to interface to Fortran code. The usual loss of performance associated with object-oriented languages has been avoided through not as obvious implementations of numerical base classes, avoiding unnecessary copying of objects. It can be thought of as some sort of reference counting done by the compiler at compile time. Supported on Linux/Unix with the GNU compiler, on Windows with the Microsoft Visual C++ (6, 7) compiler and with the Intel compiler: http://plasimo.phys.tue.nl/TBCI/. Limitations -No interface to Blas and Lapack.

Benchmarks including Seldon

Platform: Intel Core 2 Duo CPU P9500, 2.53GHz, 6 MB cache, 4 GB Ram. Compiler: gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12). Date: March 2009.

Benchmarks for Dense Matrix

Adapted from http://flens.sourceforge.net/session1/tut9.html

Benchmarks for Sparse Matrix

Adapted from http://flens.sourceforge.net/session2/tut4.html. Compiled with -DNDEBUG -O3 options for g++. Matrices of 1 000 000 lines.

1. Benchmark for sparse matrix, vector product with random initialization 5 non zero elements per line on average. In CRS Flens format, the number of non zero values stored corresponds to the number of non zero values plus the number of empty lines (one 0 is inserted on the diagonal).

Flens As a rough guide, here are some results for Trilinos. Several Trilinos packages offer at least a partial interface to Blas and Lapack routines: Epetra, Teuchos, Amesos, AztecOO, ML, MOOCHO and Pliris. The Trilinos column refers to all the packages tested together. This result is the maximum coverage and one should be careful for its interpretation. Indeed, some packages may not communicate together, with non compatible structures, and therefore could not be used together. Moreover, some of the interfaces may not be usable directly, only indirectly through other functions.

Blas

Trilinos

-

  Natural mathematical notation: e. g. y += 2 * transpose(A) * x + 1.5 * b + c without sacrificing performances (see section 3 in Appendix) -Very efficient, see benchmarks: http://flens.sourceforge.net/session2/tut4.html, http://grh.mur.at/misc/sparselib_benchmark/report.html, http://flens.sourceforge.net/session1/tut9.html and section 2.2 Portability: platforms and compilers supported -Tested on Mac OS X, Ubuntu Linux and a SUSE Opteron cluster -GCC: version 4 or higher -Intel C++ compiler (icc): version 9.1 -Pathscale (pathCC): GNU gcc version 3.3.1, PathScale 2.3.1 driver

  -No band matrices Part XII SparseLib++ SparseLib++ is a C++ class library for efficient sparse matrix computations across various computational platforms. SparseLib++ Distribution v.1.7 -after 1996 Doc. updated in 1996 http://math.nist.gov/sparselib++/ minimal maintenance, not in development 3 authors, 0 developers First release: 1994 License: Public domain (GPL compatible) Types of matrices and vectors available -Sparse double vectors -Sparse double matrices with several storage formats: compressed row/column, compressed diagonal, coordinate formats, jagged diagonal, block compressed row and skyline Linear algebra operations available -Preconditioners: incomplete LU, incomplete Cholesky and diagonal scaling -Iterative solvers: SOR, Chebyshev iteration, BiCg, BiBgStab, Cg, Cgne, Cgne, Cgnr, Gmres, MinRes and Qmr -Sparse triangular system solver Interface with other packages Blas Performance Not evaluated Portability: platforms and compilers supported Various computational platforms Installation Requires Blas Miscellaneous -Built upon sparse Blas (level 3) -SparseLib++ matrices can be built out of nearly any C++ matrix/vector classes (it is shipped with the MV++ classes by default) Limitations -Templates not supported (only double elements) -No new feature since 1996, only maintenance -No eigenvalues computation -No dense vectors and matrices Part XIII Template Numerical Toolkit (TNT) TNT is a collection of interfaces and reference implementations of numerical objects useful for scientific computing in C++. JAMA/C++ library (Java Matrix Package translated into C++) utilizes TNT for the lower-level operations to perform linear algebra operations. TNT Distribution v.3.0.11 -Jan. 2008 Doc. updated in 2003 http://math.nist.gov/tnt/ active maintenance, not in development 2 authors, 0 developers First release: Sep. 1999 License: Public domain (GPL compatible) Types of matrices and vectors available -Sparse matrices -1D, 2D and 3D arrays (row-major and column-major) Linear algebra operations available Provided by JAMA/C++: -SVD decomposition -SVD, LU, QR and Cholesky solvers -Eigenvalues computation Interface with other packages None Performance Not evaluated Portability: platforms and compilers supported ANSI C++ compatibility: should work with most updated C++ compilers (tested by the authors with Microsoft Visual C++ v.5.0) Installation By including header files Miscellaneous Templates supported Limitations -No sparse vectors -No separation between headers and sources (only header files) -Beta release since Jan. 2008 Part XIV

  Distribution 9.0.1 -Oct. 2008 Doc. updated in Oct. 2008 http://trilinos.sandia.gov/ in development 34 developers First release: Sept. 2003 License: LGPL (GPL compatible) Types of matrices and vectors available -Core kernel package (Kokkos) -Dense, symmetric dense, sparse, block sparse, jagged-diagonal sparse matrices (Epetra and EpetraExt) -Dense vectors and multivectors (Epetra and EpetraExt), sparse vectors (Tpetra) -Integer and double elements (Epetra and EpetraExt), templates (Tpetra) Linear algebra operations available -Preconditioners: ILU-type (AztecOO and IFPACK ), Multilevel (ML), Block (Meros) -Linear solvers: Direct dense solvers (Epetra and Teuchos: wrappers for selected Blas and Lapack routines, Pliris: LU solver on parallel platforms); Krylov solvers (AztecOO : preconditioned Krylov solver, Belos: iterative solver, Komplex : for complex values); Direct sparse solvers (Amesos: for DSCPACK, SuperLU, SuperLUDist and UMF-PACK); SVD decomposition (Epetra) -Nonlinear solvers: System solvers (NOX : globalized Newton methods such as line search and trust region methods, LOCA: computing families of solutions and their bifurcations for large-scale applications); Optimization (MOOCHO : reduced-space successive quadratic programming (SQP) methods); Time integration/Differential-algebraic equations (Rythmos) -Eigensolver: block Krylov-Schur, block Davidson and locally-optimal block preconditioned conjugate gradient (Anasazi ) Interface with other packages -Uses Blas and Lapack -Provides interfaces for Metis/ParMetis, SuperLU, Aztec, Mumps, Umfpack and soon PETSc -Conjunction possible with SWIG, MPI, Expat (XML parser), METIS and ParMETIS Performance Epetra provides classes to distribute vectors, matrices and other objects on a parallel (or serial) machine Portability: platforms and compilers supported Linux, MAC OS X, Windows (under Cygwin), SGI64, DEC and Solaris

  Boost C++ libraries -Mathematical notation to ease the development (use of operator overloading)Limitations-No eigenvalues computation -Only basic linear algebra (no linear solving except triangular solver) -The implementation assumes a linear memory address model -Tuning focussed on dense matrices -No separation between headers and sources (only header files)

Figure 1 :

 1 Figure 1: A x At product for dense matrices.

Figure 2 :

 2 Figure 2: At x A product for dense matrices.

Figure 3

 3 Figure 3: Y += alpha * X for dense vectors.

Figure 4 :Figure 5 :

 45 Figure 4: Matrix vector product for dense matrices and vectors.

  -Lack of portability: not recently tested on Windows (once compiled with Microsoft Visual Studio Express compiler with minor modifications in the Flens code)Types of matrices and vectors available Sparse, dense and skyline vectors and matrices Linear algebra operations available -Triangular solver, iterative generic solvers (Cg, BiCgStag, Qmr, Gmres) with preconditioners for sparse matrices (diagonal, based on MR iterations, ILU, ILUT, ILUTP, ILDLT, ILDLTT) -Reference to sub-matrices (with sub-interval, sub-slice or sub-index) for any sparse dense or skyline matrix for read or write operations -LU and QR factorizations for dense matrices -Eigenvalues computation for dense matrices Interface with other packages -Blas, Lapack or Atlas for better performance -SuperLU 3.0 (sparse matrix direct solver) for sparse matrices Performance Very efficient, see benchmarks: http://grh.mur.at/misc/sparselib_benchmark/report.html and http://eigen.tuxfamily.org/index.php?title=Benchmark

	Part V
	Gmm++
	Gmm++ is a generic matrix template library inspired by MTL and ITL.
	Gmm++	Distribution 3.1 -Sep. 2008	Doc. updated in Sep. 2008
	http://home.gna.org/getfem/gmm_intro.html
	in development 2 contributors and 2 developers First release: Jun. 2002
	License: LGPL (GPL compatible)
	Portability: platforms and compilers supported
	-Linux/x86 with g++ 3.x and g++ 4.x
	-Intel C++ Compiler 8.0
	-Linux/Itanium with g++
	-MacOS X Tiger (with the python and matlab interface)
	-Windows with MinGW and MSys (without the Python and Matlab interface)
	Installation
	No special requirement
	Miscellaneous
	-Templates supported
	-Examples of users: IceTools, an open source model for glaciers; EChem++: a problem
	solving environment for electrochemistry
	-Gmm++ is included in Getfem++, a generic and efficient C++ library for finite
	element methods, awarded by the second price at the "Trophées du Libre 2007" in the
	category of scientific softwares
	-Provides a high-level interface to Python and Matlab via Mex-Files for Getfem++,
	covering some functionalities of Gmm++
	-No eigenvalues computation
	-No sparse vectors
	-No hermitian matrices

  5.2 -Jul. 2007 Doc. updated in Jul. 2007 http://lapackpp.sourceforge.net/ in development 7 developers First release: 1993 License: LGPL (GPL compatible) Types of matrices and vectors available -Int, long int, real and complex vectors and matrices -Symmetric positive definite matrix -Symmetric, banded, triangular and tridiagonal matrices Linear algebra operations available -Linear systems solving for non-symmetric matrices, symmetric positive definite systems and solving linear least-square systems; using LU, Cholesky and QR matrix factorizations -Symmetric eigenvalues computation -SVN and QR decompositions MTL is a generic component library developed specially for high performance numerical linear algebra. MTL includes matrix formats and functionality equivalent to level 3 Blas. MTL 4 Distribution alpha 1 -Oct. 2007 Doc. updated in Nov. 2008 http://www.osl.iu.edu/research/mtl/mtl4/ in development 4 developers First release: 1998 (MTL2) License: Copyright Indiana University (can be modified to become GPL compatible) Types of matrices and vectors available -Dense2D, morton dense and sparse matrices -Arbitrary types can be used for matrix elements (float, double, complex) Linear algebra operations available -Preconditioners: diagonal inversion, incomplete LU factorization without fill-in and incomplete Cholesky factorization without fill-in -Solvers: triangular, conjugate gradient, BiCg, CgSquared and BiCgStab -Iterative methods for solving linear systems thanks to the Iterative Template Library (ITL, last release in Oct. 2001): Chebyshev and Richardson iterations, generalized conjugate residual, generalized minimal residual and (transpose free) quasi-minimal residual without lookahead Interface with other packages Blas (optionally Blitz++ thanks to ITL) Performance -Natural mathematical notation without sacrificing performances: A = B * C dispatched to the appropriate Blas algorithm if available; otherwise an implementation in C++ is provided (also reasonably fast, usually reaching 60 percent peak) -See benchmarks: http://grh.mur.at/misc/sparselib_benchmark/report.html, http://eigen.tuxfamily.org/index.php?title=Benchmark and http://projects.opencascade.org/btl/ PETSc, the Portable, Extensible Toolkit for Scientific computation, is a suite of data structures and routines for the scalable (parallel) solution of scientific applications modeled by partial differential equations. Linear algebra operations available -Preconditioners: ILU, LU, Jacobi, block Jacobi, additive Schwartz and ICC -Direct solvers: LU, Cholesky and QR -Krylov subspace methods: GMRES, Chebychev, Richardson, conjugate gradients (Cg), CGSquared, BiCgStab, two variants of TFQMR, conjugate residuals and Lsqr -Nonlinear solvers: Newton-based methods, line search and trust region -Parallel timestepping solvers: Euler, Backward Euler and pseudo time stepping Interface with other packages Blas, Lapack, ADIC/ADIFOR, AnaMod, BlockSolve95, BLOPEX, Chaco, DSCPACK, ESSL, Euclid, FFTW, Hypre, Jostle, Mathematica, Matlab, MUMPS, ParMeTiS, Party, PaStiX, PLapack, Prometheus, Scotch, SPAI, SPOOLES, SPRNG, Sundial/CVODE, SuperLU, Trilinos/ML, UMFPACK Seldon is a C++ library for linear algebra. Seldon is designed to be efficient and convenient, which is notably achieved thanks to template classes. Linear algebra operations available -Preconditioner of your own or by successive over-relaxations (SOR) -Direct dense solvers: LU, QR, LQ and SVD decomposition -Iterative solvers: BiCg, BiCgcr, BiCgStab, BiCgStabl, Cg, Cgne, Cgs, CoCg, Gcr, Gmres, Lsqr, MinRes, QCgs, Qmr, QmrSym, SYMmetric, Symmlq and TfQmr -Eigenvalues and eigenvectors computation Interface with other packages -Fully interfaced with Blas (level 1, 2 and 3) and Lapack, except for functions with banded matrices -Direct sparse solvers: MUMPS, SuperLU and UmfPackLU

	Part IX -No release since the alpha version in Oct. 2007 Part X Part XI
	Matrix Template Library (MTL) PETSc Seldon
	Seldon	Distribution 2008-11-12 -Nov. 2008 Doc. updated in Nov. 2008
	PETSc http://seldon.sourceforge.net/ Distribution 2.3.3 -May 2007 Doc. updated in Jul. 2008
	http://www.mcs.anl.gov/petsc/petsc-2/ in development 2 developers	First release: Nov. 2004
	in development 11 developers License: GPL (GPL compatible)	First release: Mar. 1999
	License: Copyright University of Chicago (GPL compatible) Types of matrices and vectors available Types of matrices and vectors available -Dense and sparse vectors -Parallel vectors and matrices -Dense matrices: several formats for rectangular, symmetric, hermitian and triangular -Several sparse matrices storages -Two sparse matrix forms: Harwell-Boeing and array of sparse vectors -Symmetric, block diagonal and sequential matrices -3D arrays
	Interface with other packages
	-Blas
	-Lapack
	Performance
	High performance linear algebra computation
	Portability: platforms and compilers supported Performance
	-Linux/Unix: gcc2.95.x, gcc3.x and gcc4.x Very efficient, see benchmarks in section 2.2 Performance -Windows 9x/NT/2000: MinGW and gcc3.x -Windows 9x/NT/2000: Microsoft Visual Studio, .NET and MSVC Optimal on parallel systems with high per-CPU memory performance Portability: platforms and compilers supported
	-Mac OS X Installation -Code fully compliant with the C++ standard Portability: platforms and compilers supported -OS Portable Any compiler supporting ANSI C standard on Unix or Windows -GNU GCC ≥ 3 (from 3.2 to 4.3 tested); Intel C++ compiler icc (icc 7.1 and 8.0
	Requires Blas, Lapack and a Fortran compiler Miscellaneous Portability: platforms and compilers supported tested); compile with Microsoft Visual Installation Can be compiled and used on any target platform with an ANSI C++ compiler -Linux: g++ 4.0.1, g++ 4.1.1, g++ 4.1.2, g++ 4.2.0, g++ 4.2.1, g++ 4.2.2, icc 9.0 Requires Blas, Lapack, MPI and optional packages Installation
	-Template functions for matrices -Templates not supported, float supported only for general matrices -No sparse matrices Miscellaneous optimization -No sparse vectors surgery, geosciences, environment, computational fluid dynamics, wave propagation and Requires the Boost library included, optionally scons and a Blas library installed -Scientific applications in many fields such as nano-simulations, cardiology, imaging and Installation OOFEM, DEAL.II and Python bindings (petsc4py and LINEAL) Limitations -Windows: VC 8.0 from Visual Studio 2005 -Related packages using PETSc such as TAO, SLEPc, Prometheus, OpenFVM, -Macintosh: g++ 4.0.1 Miscellaneous Requires Blas and CBlas
	-Templates and generic programming -A generic library has been Limitations -No sparse vectors http://www.osl.iu.edu/research/itl/) -Not coded in C++ but in C -Developed from scratch but inspired by the design and implementation details of built on top of MTL (ITL: MTL 2 (interfacing Lapack; supporting sparse, banded, packed, diagonal, tridiagonal, -Templates not supported, polymorphism used instead
	triangle, symmetric matrices)
	Limitations
	-No sparse vectors
	-No eigenvalues computation

  /flens.sourceforge.net/session2/tut4.html, http://flens.sourceforge.net/session1/tut9.html, http://eigen.tuxfamily.org/index.php?titl http://projects.opencascade.org/btl/ and and section 2.2

	Part XV
	uBlas
	uBlas is a C++ template class library that provides Blas level 1, 2, 3 functionality
	for dense, packed and sparse matrices.
	uBlas		Distribution 1.33.0 -Jul. 2008 Doc. updated in 2008
	http://www.boost.org/doc/libs/1_35_0/libs/numeric/ublas/
	in development 5 developers		First release: 2008
	License: Boost Software License (GPL compatible)
	Types of matrices and vectors available
	-Dense, unit and sparse (mapped, compressed or coordinate) vectors
	-Dense, identity, triangular, banded, symmetric, hermitian, packed and sparse (mapped,
	compressed or coordinate) matrices
	Linear algebra operations available
	-Submatrices and subvectors operations
	-Triangular solver
	-LU factorization
	Interface with other packages
	Blas (level 1, 2 and 3)
	Performance
	Optimized	for	large	vectors	and	matrices,	see	benchmarks:
	http:/Portability: platforms and compilers supported
	OS Independent, requires a modern (ISO standard compliant) compiler such as GCC

Table 1 :

 1 Flens and Seldon performance benchmarks using overloaded operators. Available Interfaces toBlas and Lapack Routines (Trilinos)

			Seldon
	initialization 0.35s finalization 1.23s	1.48s
	y = Ax	1.28s	1.3s
	y = A'x	1.61s	1.49s
	2. Benchmark with initialization in order and tridiagonal matrix
	3 non zero elements per line (except on first and last lines with only 2 non zero
	elements).
		Flens	Seldon	Seldon
			(matrix built by hand) (matrix built with a generic algorithm *)
	initialization 0.28s finalization 0.16s	0.08s	0.1s
	y = Ax	0.19s	0.18s	0.18s
	y = A'x	0.22s	0.22s	0.22s
	*using MergeSort on already sorted vectors, instead of QuickSort used in random
	initialization case.
	3. Benchmark for computation of the residual
	5 non zero elements per line on average.
			Flens Seldon
	initialization finalization		1.34s 1.25s	2.46s
	computations r = b -Ax 1.39s	1.35s

  Epetra Teuchos Amesos AztecOO ML MOOCHO Pliris

	Total	87	28	62	18	21	29	34	28
	Coverage	60%	19%	42%	12%	14%	20%	23%	19%
	Single real Lapack	Trilinos Epetra Teuchos Amesos AztecOO ML MOOCHO Pliris
	Total	57	44	44	4	8	32	1	1
	Coverage	31%	24%	24%	2%	4%	17%	1%	1%
	Double real Lapack	Trilinos Epetra Teuchos Amesos AztecOO ML MOOCHO Pliris
	Total	59	43	44	4	7	32	7	0
	Coverage	32%	23%	24%	2%	4%	17%	4%	0%
	Single complex Lapack	Trilinos Epetra Teuchos Amesos AztecOO ML MOOCHO Pliris
	Total	39	1	38	1	1	1	0	0
	Coverage	20%	1%	20%	1%	1%	1%	0%	0%
	Double complex Lapack Trilinos Epetra Teuchos Amesos AztecOO ML MOOCHO Pliris
	Total	38	0	38	1	0	0	0	0
	Coverage	20%	0%	20%	1%	0%	0%	0%	0%

Acknowledgement

This document benefits from discussions with Vivien Mallet, Dominique Chapelle and Philippe Moireau, and also from corrections thanks to Xavier Clerc.

Part XVI Other Libraries

Armadillo++ is a C++ linear algebra library providing matrices and vectors, interfacing Lapack and Atlas. : http://arma.sourceforge.net/. Limitations -No templates (only double), early development (first release in Apr. 2008), no portability under Windows without Cygwin.

Blitz++ is a C++ class library for scientific computing providing high performance by using template techniques. The current versions provide dense arrays and vectors, random number generators, and small vectors and matrices: http://www.oonumerics.org/blitz/. Limitations -No sparse matrices and vectors. Barely relevant for linear algebra.

CPPScaLapack is a C++ class wrapper for BLACS, PBlas and ScaLapack with MPI. CPPScaLapack provides a user-friendly interface of high-speed parallel matrix calculation with Blas and Lapack techonologies for programers concerning with largescale computing: http://cppscalapack.sourceforge.net/. Limitations -Still an alpha program, no sparse matrices and vectors, no templates (only double-precision vectors and general matrices).

CVM Class Library provides vector and different matrices including square, band, symmetric and hermitian ones in Euclidean space of real and complex numbers. It utilizes Blas and Lapack. Contains different algorithms including solving of linear systems, singular value decomposition, non-symmetric and symmetric eigenvalue problem (including Cholesky and Bunch-Kaufman factorization), LU factorization, QR factorization: http://www.cvmlib.com/. Limitations -Templates supported but distinction between real and complex types. No sparse matrices and vectors.

IML++ (Iterative Methods Library) is a C++ templated library for solving linear systems of equations, capable of dealing with dense, sparse, and distributed matrices: http://math.nist.gov/iml++/. Limitations -No matrices and vectors, only iterative solvers.

LA library is a C++ interface to Blas and Lapack providing also a general (sparse) matrix diagonalization, linear solver and exponentiation templates : http://www.pittnerovi.com/la/. Limitations -Portability: tested only on Linux with a code not fully ANSI C++ compliant.

LinAl The library is based on STL techniques and uses STL containers for the storage of matrix data furthermore STL algorithms are used where feasible. Low level, algebraic operators as well as linear solvers and eigenvalue solvers are implemented, based on calls to Blas, Lapack and CGSOLX and LANCZOS: http://linal.sourceforge.net/LinAl/Doc/linal.html. Limitations -No vectors, no sparse matrices.

LinBox is a C++ template library for exact, high-performance linear algebra computation with dense, sparse, and structured matrices over the integers and over finite fields: http://www.linalg.org/. Limitations -Does not suit to real and complex values.

Part XVII

Links and Benchmarks 1 Links

Here are some Web portals related to numerical analysis software and linear algebra libraries:

- . 2008). The first two libraries satisfy the main requirements exposed in section I, and Trilinos was supposed to be a good reference as for the coverage of Blas and Lapack.

Flens Overloaded Operator Performance Compared to Seldon

Flens implements a user-friendly interface to Blas routines by overloading operators. For example, one can add vectors by using mathematical symbols: y = a + b + c. Here are a few tests to check if this does not imply any loss of performance in the computation.

In table 1 are presented CPU times measured with std::clock() for several operations, for RowMajor (R.) and ColMajor (C.) matrices. In the following, lower-case letters denote vectors and upper-case letters denote matrices. Y = A + B cannot be used for sparse matrices in Flens, so this has been tested only on general dense matrices.

In ColumnMajor format for Flens, the affectation operation Y = A costs much more (1.48s) than in RowMajor format (0.35s). This lack of performance slows down sum operations such as Y = A + B. This is due to a direct call to Blas to copy the data (a memory block copy in C++ is used in Seldon).

In ColumnMajor for Seldon, matrix vector product such as Y += transpose(A)*B is three times longer than in Flens. This is due to a call to a generic function instead of the Blas routine. Taking advantage of a local knowledge of Seldon (one of its authors, Vivien Mallet, is part of my team!), we have fixed this bug and got the same results as in Flens for y += transpose(A)*b and y +=2*transpose(A)*b + 1.5*c + d.

Double precision complex


Claire Mouton
email: claire.mouton@inria.fr

I X Talos

Configuration File Parser Library

Introduction

The two basic methods to pass parameters to the main()-routine are: input files and command line arguments. For small scale programs these input methods allow to change parameters without having to recompile or having to create an input file parser. Even for large programs input files and command line arguments are a comfortable way to replace annoying graphical user interfaces. When debugging complicated code, it is essential to be able to isolate code fragments into a lonely main()-routine. In order to feed these isolated code fragments with realistic data, sophisticated command line and input le parsing becomes indispensable (excerpt from GetPot documentation).

Part I Requirements

This document has been written to help in the choice of a configuration file parser library to be included in Verdandi, a scientific library for data assimilation. The main requirements are 1. Portability: Verdandi should compile on BSD systems, Linux, MacOS, Unix and Windows. Beyond the portability itself, this often ensures that most compilers will accept Verdandi. An obvious consequence is that all dependencies of Verdandi must be portable, especially the configuration file parser library.

2. The configuration file parser library should be written in C++, possibly in C, to be called from Verdandi written in C++.

3. License: any dependency must have a license compatible with Verdandi licenses (GPL and LGPL).

4. The library must provide the functionality of creating sections in the configuration file.

Part II Configuration File Parser supports both shared as well as static binding of binaries. Provides API for both manual and automatic processing of configuration file entries : http://sourceforge.net/projects/parser. Limitations -Written in C.

Config

ConfigParser reads and writes configuration files with a syntax similar to C/C++; after being read in a configuration file, the configuration data is available for access, modification and removal, or can also be written back to a file: http://www.codedread.com/code.php#Config. Limitations -Not maintained, not portable (only Windows executable without source code).

Confix

  : http://www.flipcode.com/archives/Configuration_File_Parser.shtml. Limitations -IBM Public license not compatible with GPL license. dot.conf : http://www.azzit.de/dotconf/. Limitations -Written in C, no activity since 2003. dotconfpp : http://ostatic.com/dotconfpp/. Limitations -Not portable (distribution FreeBSD for i386).

  /www-personal.umich.edu/ ~wagnerr/ConfigFile.html. Limitations -Impossible to define sections in configuration files.

	Part III Part IV Part V Part VI Part VII Part VIII Part X
	GetPot libcfgparse libconfig libConfuse Program options RudeConfig Other Libraries
	Config Distribution 1 -May 2008 Doc. updated in May 2008 http://www.codeproject.com/KB/files/config-file-parser.aspx License: LGPL (GPL compatible) Language: C++ GetPot Distribution 1.1.18 -Jul. 2008 Doc. updated in Mar. 2007 http://getpot.sourceforge.net/ License: LGPL (GPL compatible) Language: C++, Java, Python, Ruby libcfgparse Distribution 0.6 -Dec. 2005 Doc. updated in Dec. 2005 http://freshmeat.net/projects/libcfgparse/ License: GPL (GPL compatible) Language: C libconfig Distribution 1.3.2 -Feb. 2009 Doc. updated in Feb. 2009 http://www.hyperrealm.com/libconfig/ License: LGPL (LGPL and GPL compatible) Language: C++ libConfuse Distribution 2.6 -Dec. 2007 Doc. updated in 2004 Program options Distribution 1.38.0 -? Doc. updated in Nov. 2007 RudeConfig Distribution 5.0.5 -released in ? Doc. updated in ? A Configuration Package : http://alumni.media.mit.edu/ ~rahimi/configuration/. http://www.nongnu.org/confuse/ License: LGPL (GPL compatible) License: Boost Software License (GPL compatible) Language: C++ License: GPL (GPL compatible) Language: C++ Language: C http://www.boost.org/doc/libs/1_38_0/doc/html/program_options.html http://rudeserver.com/config/ Limitations -Based on Lex and Yacc, no activity since 2001.
	Main features -Configuration files may be sub-structured arbitrarily deep -Configuration files support the expansion of symbolic values from previ-ously defined variables and environment variables Portability: platforms and compilers supported Only standard C++ (code is cross platform) -MSVS Express 2005 project files are included Main features -Parses comand line arguments, single or multiple configuration files -Variables can be sorted into sections and subsections Main features -C, C++ and Python API -Configuration file syntax is similar to C -Allows to keep data structured as lists and records; by this allows to group variables together to handle them conveniently -Built-in variable types: string, boolean, integer and floating-point -Allows pre-definitions of types and declaration of default values -Allows for strict type-checking Main features -A fully reentrant parser: independent configurations can be parsed in concurrent threads at the same time -Both C and C++ bindings, as well as hooks to allow for the creation of wrappers in other languages -A low-footprint implementation (just 38K for the C library and 66K for the C++ library) that is suitable for memory-constrained systems -Proper documentation Main features -Supports sections and (lists of) values (strings, integers, floats, booleans or other sections), as well as some other features (such as single/double-quoted strings, environment variable expansion, functions and nested include statements) Main features -Reads key/value pairs from command line, a configuration file and environment variables -Good documentation and tutorial ccl (Customizable Configuration Library) allows the comment, key/value Main features and string literal delimiters to be programatically specified at runtime. -Independent core library designed for CGI (Common Gateway Interface) Simple, portable with a small interface consisting of five functions : -Reads and writes configuration / .ini files http://sbooth.org/ccl/. -Provides fully customizable delimiters and comment characters, ensuring Limitations -Written in C. compatibility with most existing configuration / .ini file formats -No myriads of features in a simple API making it easy to use and quick to integrate with one's code Portability: platforms and compilers supported Portability: platforms and compilers supported Any platform -Allows multiline values using backslash escapes CFL (Configuration File Library). Portable, requires GDSL library: -Comments within the configuration file are fully preserved when the http://home.gna.org/cfl/. contents are re-saved -Deleted values can become commented out when the object is re-saved, Limitations -Written in C.
	-Manual build successfully tested with GNU g++/Linux -Allows to parse data directly from memory without a file Installation preserving old data
	Installation Portability: platforms and compilers supported Portability: platforms and compilers supported -Linux, Solaris and Mac OS X Program options is one of the Boost C++ Libraries ConfigFile C++ portable code -LGPL license can be provided by the author if needed with Installation http:/	templates:
	-Windows 2000/XP and later: gcc in the MinGW environment or with Limitations Portability: platforms and compilers supported
	Limitations Sub groups less easy to create and read than with GetPot (requires an check-ing) Visual Studio 2005 Borland, Visual C++ 6.0 and Linux Limitations Installation Requires yacc and lex Installation Written in C Installation -Several styles of comment available for configuration files iterator on a STL map) -Emacs syntax highlighting for GetPot files Limitations -Provides a Python port -Requires yacc and lex (so designed for Unix operating system) tary context -No maintenance, not in development Configuration file syntax similar to C++ (quite heavy with {} and ; ) -Non-military usage only, but civil applications are allowed even in a mili--Preliminary documentation Limitations Limitations
	Portability: platforms and compilers supported -Written in C (but provides a C++ API)
	Platform independent (istream problem with carriage return/newline on Mi-
	crosoft Visual Studio should be solved)
	Installation
	-Easy to install: contained in one single header file
	-Requires STL library
	Limitations
	-No exceptions thrown (for example, no error message when a file is not
	found; when numeric expressions have a wrong type, refer to non-existent
	variables), a default value is returned if a key is not found in the input file
	-Subsection definition is not intuitive and not flexible if './' syntax is used,
	better to use only full subsection names

-Many features, such as unrecognized object detection (but I found a bug...) and prefixes allowing to focus on variables in a given section -Easy to use thanks to detailed, organized and commented example files (see: http://getpot.sourceforge.net/example.html) -Provides a language allowing a variety of operations on variables, numbers and strings inside a configuration file (recursive replacements, conglomerate variable names, dictionaries; concatenation and replacement in strings; power expressions, comparisons and conditions in numeric expressions (see example file: http://getpot.sourceforge.net/expand.html)) -The user can define and name its own variables (the parser finds them) -GetPot can be used to emulate trivial function calls (without syntax

Part IX Talos

Talos Distribution 1. 0 -Apr. 2007Doc. updated in Oct. 2004 http://vivienmallet.net/lib/talos/ License: GPL (GPL compatible) Language: C++

Main features

Provides miscellaneous functions and objects, such as -Functions to deal with strings and files that C++ is missing -An extended ifstream class -Two classes to read flexible configuration files: one for a single configuration file and another for multiple configuration files


Claire Mouton

Alternatives for the High-Level Interface to the Data Assimilation Library

Alternatives for the High-Level Interface to the Data Assimilation Library

Claire Mouton -claire.mouton@inria.fr November 2008

Part I

Requirements

The various solutions to interface the library should be evaluated bearing in mind the following constraints:

• The maintenance cost should be minimum. This implies an almost automatic building of the interface to include any change in the C++ code.

• The interface should give access to all functions, objects and methods of the C++ code. Note that a library defines a large number of functions and objects.

The high-level language can be either Python or Matlab or both. Elements to compare Python and Matlab can be found here: http://mail. and Python with minimal effort: a small number of directives are added to the program header files and within an interface file, and the SWIG tool then creates the source code which provides the "glue" between C/C++ and Python.

SWIG provides wrapping support for almost all of ANSI C++ such as:

• Overloaded functions and methods,

• Overloaded operators,

• Templates,

• C++ library support for strings and the STL.

2 Other Existing Tools Boost.Python is a C++ library which enables seamless interoperability between C++ and the Python programming language (http://www.boost.org/doc/libs/1_37_0/libs/python/doc/index.html). It is designed to wrap C++ interfaces as unobtrusively as possible. It is a very rich wrapper interface including support for:

• Function overloading,

• C++ to Python exception translation,

• Default arguments, It also presents a Matlab module (http://garr.dl.sourceforge.net/sourceforge/swig/swig1.1p5.tar.gz). This is a highly experimental language module that allows SWIG to create native Matlab cMEX wrappers. That is, one can take a C library and turn it into a working Matlab module. Limitations -This module has only been tested with Matlab 5.0 under Windows NT-4.0. No support for C arrays or mapping between Matlab matrices and arrays has been implemented. It is not developed any more. It remains undocumented and essentially untested.

SwigMatlabPlus is a simple extension of this SWIG module (http://alumni.media.mit.edu/ ~sbasu/code/swigmatlabplus/), under MIT license. This allows to take C++ code and export it to Matlab. This gives access to C++ objects, member variables, and methods from Matlab. A support for vectors/matrice has been added. Limitations -This is only available for Visual C++.

In May 2008, a Matlab branch was created in the SWIG public repository (http://swig.svn.sourceforge.net/viewvc/swig/branches/matlab-branch/). This branch aims at experimenting with making Octave module generate Matlab MEX-files. Limitations -Development on this branch did not get far at all. However, the work to port the Octave backend to Matlab MEX-files does not require an outrageous amount of work. If one is interested in moving it forward, the author of the Octave backend (Xavier Delacour) would be willing to provide guidance and explanation.

MEX-files

MEX is a built-in utility that enables to call C, C++ or Fortran code in Matlab by compiling the code into a Matlab Executable called a MEXfile (http://www.mathworks.com/support/compilers/interface.html). MEX-files are dynamically linked subroutines that are called as regular Matlab functions. Limitations -MEX-files have a specific syntax. The application main() has to be replaced with a special gateway function (called "MEXFunction") to pass inputs and outputs to and from Matlab. In C++, function argument checking is done at compile time. In Matlab and with MEX-files, any number or type of arguments can be passed to a MEX-function, which is responsible for argument checking to be written manually. It does not match with the low maintenance cost requirement.

Matwrap

Matwrap is a wrapper generator for matrix languages such as Matlab,

Octave or Tela (http://lnc.usc.edu/ ~holt/matwrap/), available free of charge under the terms of the artistic license (http://www.perl.com/language/misc/Artistic.html). It is a Perl script that generates wrapper functions automatically from .h files. Limitations -It was developed for Matlab version 5 and it has not been adapted to the latest version. Furthermore, it was compiled with gcc 2.7.2, and has not been tested on other compilers. It does not support template programming, function overloading, operator definition, function and member function pointers.

Interface via Octave

An interface to Matlab can be built through Octave.

The first step is to build an interface to Octave via SWIG (see section 1). The second step is to convert the code from Octave to Matlab.

To do so, Oct2Mat can be applied to the files (http://users.powernet.co.uk/kienzle/octave/oct2mat.tar.gz). This is an awk script supporting the main differences between Octave and Matlab. Limitations -It was created for and tested with Matlab 4. Oct2Mat needs the implementation of some features to be complete, such as: • Solving confusion with transpose operator when appearing on a line containing a string,

• Handling Octave builtin variables.

Matlab through Python

PyMat exposes the Matlab engine interface allowing Python programs to start, close, and communicate with a Matlab engine session. In addition, the package allows transferring matrices to and from a Matlab workspace. These matrices can be specified as NumPy arrays, allowing a blend between the mathematical capabilities of NumPy and those of Matlab. For instance, this allows to plot NumPy arrays in a Matlab plot window. For further information: http://pymat.sourceforge.net/.

Mlabwrap (based on PyMat) is a high-level Python-to-Matlab bridge: it makes Matlab look like a normal Python library. Beta version under BSD License or MIT License available from http://mlabwrap.sourceforge.net/.

•

  Converting function [x y]=... to function [x, y]=..., • Converting y to y , • Converting x=y=Z; to y=Z; x=y;, • Variable argument/return lists,

  The aim is to achieve the connection between the C++ code

		python.org/pipermail/python-list/2003-January/827579.html
	and	from	page	54	to	page	80	there:
	http://web.bryant.edu/ ~bblais/bryant/numerical_computing/python_matlab.pdf.
	Part II
	C++ to Python Interface
	1 SWIG
	SWIG (Simplified Wrapper and Interface Generator) is an open
	source software tool used to connect programs or libraries written in
	C/C++ with eighteen different languages such as Python and Octave
	(http://www.swig.org/). The current version is SWIG-1.3.35 released in
	April 2008.

  PyQt (the Python bindings for the Qt toolkit) and PyKDE. C++ templates are supported. It does not appear to be specifically tied to Qt, but does not seem to have gained general acceptance with the rest of the Python Community.

	SIP (based on SWIG) is a tool that makes it easy
	to	create	Python	bindings	for	C	and	C++	libraries
	(http://www.riverbankcomputing.com/software/sip/intro).	It was
	used to build

•

  Exporting C++ iterators as Python iterators.Weave allows the inclusion of C/C++ within Python code and is useful in accelerating Python code (http://www.scipy.org/Weave). Weave is a subpackage of SciPy. It is a way to optimize time critical code.Instant is a Python module that allows for instant inlining of C and C++ code in Python (http://www.fenics.org/wiki/Instant). It is a small Python module built on top of SWIG. SWIG-1.1, the second SWIG version released in 1997, only covers Tcl, Perl and Python.

	Examples	using	these	tools can	be	found	there:
	http://www.suttoncourtenay.org.uk/duncan/accu/integratingpython.html.
	Part III
	C++ to Matlab Interface
	3 Direct Interface
	3.1 Swig for Matlab
	It		seems	that	Boost.Python		wrappers
	can	be	generated	automatically		with	Py++
	(http://www.language-binding.net/pyplusplus/pyplusplus.html). It
	prevents from updating the code generator script every time the source
	code is changed.


Sylvain Gouttebroze

Weitao Liu

Michel Bellet

Hervé Combeau

2D/3D SIMULATION OF MACROSEGREGATION: A COMPARISON BETWEEN CODES ON A SMALL CAVITY AND ON A LARGE INGOT

Keywords: macrosegregation, solidification, finite elements, finite volume

This paper presents the coupled resolution of momentum, energy and solute conservation equations, for binary alloys by three different codes. The microsegregation is governed by the lever rule and the liquid flow in the mushy zone is modeled by a Darcy law. A 2D FV code, SOLID, a 2D FE code, R2SOL and a 3D FE code, THERCAST, are compared on an academic case on which experimental measurements have been done by Hebditch and Hunt, and on a benchmark steel ingot for industrial application. An adaptive anisotropic remeshing technique is used in each FE codes. For both codes, this technique is shortly described.

Introduction

Conservation equations over the two-phase mushy domain involved in alloy solidification may be obtained either by the classical mixture theory [START_REF] Prakash | On the Numerical Solution of Continuum Mixture Equations Describing Binary Solid-Liquid Phase Change[END_REF][START_REF] Bennon | A Continuum Model for Momentum, Heat and Species Transport in Binary Solid-Liquid Phase Change Systems -I. Model Formulation[END_REF] or by spatial averaging techniques [START_REF] Ni | A Volume-Averaged Two-Phase Model for Transport Phenomena during Solidification[END_REF][START_REF] Ahmad | Numerical Simulation of Macrosegregation: a Comparison between Finite Volume Method and Finite Element Method Predictions and a Confrontation with Experiments[END_REF]. While the former gives rise to simpler single-phase-like equations, the latter clarifies the relationship between macro and microscopic scale phenomena. But both theories lead to similar results. The main objective of the present work is the prediction of the macrosegregation pattern in solidifying binary alloys in ingots. To achieve this goal, a remeshing technique has been introduced in FE codes (R2SOL and THERCAST). After presenting the equations and the resolution strategy, we will describe the criteria used to define the mesh size and anisotropic factors. The results obtained by these two FE codes on two tests (small and large ingot) will be compared to those of SOLID, a finite volume two-dimensional code developed by Combeau et al [START_REF] Combeau | Numerical Study of Heat and Mass ransfer during Solidification of Steel Ingots[END_REF]. The codes have been previously compared on the same small ingot but without remeshing [START_REF] Bellet | A 3D-FEM model solving thermomechanics and macrosegregation in binary alloys solidification[END_REF]. We will see here the improvements particularly on segregated channels prediction. Adaptive remeshing is also a necessary step to simulate large ingot solidification with F.E.M. So our new efficient remeshing strategy opens the way to introduce the coupling with solid deformation and air gap formation.

Governing Equations and Resolution

The analysis of fluid flow, temperature and solute distribution in a solidifying material amounts to the coupled solution of the equations stating the conservation of mass, momentum, energy and solute. The following numerical discretization and scheme concern only the two FE codes R2SOL and THERCAST. For information on SOLID numerical resolution we refer to [START_REF] Combeau | Numerical Study of Heat and Mass ransfer during Solidification of Steel Ingots[END_REF].

Simplifying Hypotheses. The present model of binary-alloy solidification is based upon the following hypotheses. We refer to [START_REF] Voller | The Modelling of Heat, Mass and Solute Transport in Solidification Systems[END_REF] for a discussion on their range of validity.

• The liquid flow is laminar, Newtonian, with a constant-viscosity µ. The solid phase is fixed and non deformable.

• The mushy region is modeled as an isotropic porous medium saturated with liquid (i.e.: 1 = + l s g g , g s denoting the volumic solid fraction and g l the liquid one). Its permeability Κ is defined by the Carman-Kozeny formula, in which λ 2 is the secondary dendrite arm spacing:

180 / ) 1 ( 2 3 2 2 - - = Κ l l g g λ .
• The solid and liquid phase densities are equal (ρ=ρ s =ρ l ) and constant (ρ=ρ 0 ), except in the buoyancy term of the momentum equation where density depends on the temperature T and the solute concentration in liquid w l according to the Boussinesq approximation

)) ( ) ( 1 ( 0 0 0 l l w T w w T T - - - - = β β ρ ρ
, in which β T and β w are the thermal and solutal expansion coefficients, respectively.

• The microsegregation is governed by the lever rule. Given k the partition coefficient at solid-liquid interface, the average solute concentration w is related to w l by:

l l l l s l l w k g g kw g w g w ) ) 1 ( ( - + = + = (1)
• The phase diagram is linearized, the liquidus slope m being constant and T m being the melting temperature of the pure substance, we have:

l m mw T T + = (2)
Mass Conservation. Denoting V the average velocity (here equal to the average liquid velocity, since the solid is fixed), the mass conservation equation is reduced to:

0 = ⋅ ∇ V (3)
Momentum Conservation. The classical mixture theory [START_REF] Prakash | On the Numerical Solution of Continuum Mixture Equations Describing Binary Solid-Liquid Phase Change[END_REF][START_REF] Bennon | A Continuum Model for Momentum, Heat and Species Transport in Binary Solid-Liquid Phase Change Systems -I. Model Formulation[END_REF] yields (4), while the averaging technique [START_REF] Ni | A Volume-Averaged Two-Phase Model for Transport Phenomena during Solidification[END_REF][START_REF] Ahmad | Numerical Simulation of Macrosegregation: a Comparison between Finite Volume Method and Finite Element Method Predictions and a Confrontation with Experiments[END_REF] leads to (5) [START_REF] Combeau | Numerical Study of Heat and Mass ransfer during Solidification of Steel Ingots[END_REF] where p is pressure and g the gravity vector. While the FV code SOLID and R2SOL are based on [START_REF] Combeau | Numerical Study of Heat and Mass ransfer during Solidification of Steel Ingots[END_REF], THERCAST is originally based on (4), but also considers [START_REF] Combeau | Numerical Study of Heat and Mass ransfer during Solidification of Steel Ingots[END_REF]. The time-discretized form of ( 4) and ( 5) is obtained using the Euler-backward scheme. The spatial discretization is carried out using a P1/P1 tetrahedral finite element, with SUPG-PSPG stabilization [START_REF] Tezduyar | Finite element stabilization parameters computed from element matrices and vectors[END_REF].

V g V V V V Κ - + ∇ - ∇ ⋅ ∇ = × ⋅ ∇ + ∂ ∂ µ ρ µ ρ ρ p t ) ( ) ( 0 0 (4) V g V V V V l l l l g g p g g t Κ - + ∇ - ∇ ⋅ ∇ = × ⋅ ∇ + ∂ ∂ µ ρ µ ρ ρ ) ( ) ( 0 0
Solute Conservation. Redistribution of solute is governed by equation ( 6), where ε is a diffusion coefficient, usually negligible (and kept arbitrarily small). Following Voller et al [START_REF] Voller | The Modelling of Heat, Mass and Solute Transport in Solidification Systems[END_REF], the timeintegrated version of ( 6) is written as [START_REF] Voller | The Modelling of Heat, Mass and Solute Transport in Solidification Systems[END_REF].

( ) 0 . . = ∇ ∇ - ∇ + ∂ ∂ l l w w t w ε V (6) ( ) ( ) ( ) [ ] * * * * . . . . l l t t t w w w w w w t w w - ∇ ∇ - - ∇ = ∇ ∇ + ∇ + ∆ - ∆ - ε ε V V (7)
It will be seen further that the super-index * refers either to the value at the previous time instant t-∆t, in case of weak coupling, or to the latest iterative estimate in case of strong coupling. The weak form of ( 7) is solved by the Streamline Upwind/Petrov-Galerkin method.

Energy Conservation. The heat equation can be written as follows, given the above assumptions:

( ) 0 . . = ∇ ∇ -       ∇ + ∂ ∂ T H t H l λ ρ V ( 8
)
where λ is the average thermal conductivity and H is the average enthalpy:

L g d c H l T T p + = ∫ 0 τ (9)
c p being the specific heat (assumed constant) and L the latent heat. Linear tetrahedral elements and an Euler-backward scheme are used to discretize [START_REF] Tezduyar | Finite element stabilization parameters computed from element matrices and vectors[END_REF] in space and time, respectively. In each element, a constant value of T H ∂ ∂ / is used, in order to solve a weak form of ( 8) for the nodal enthalpies, also using SUPG.

Resolution Strategy. In the context of a Eulerian (fixed mesh) resolution, the resolution algorithm over a time increment is described in box 1. It can be seen that some resolution steps are iteratively chained in case of full coupling. The superscription * indicates the current estimate during iterations. In case of weak coupling the step 1 is solved with w assumed constant and equal to the local value given by ( 7) just before the point begins to solidify.

Adaptive Anisotropic Remeshing Strategy

The goal is a dynamic mesh refinement in the mushy zone in order to provide an accurate prediction of the flow field. With these conditions, the prediction of macrosegregation could be done efficiently. The main idea of the adaptive remeshing is to identify during the simulation the areas that need a remeshing, depending on some determinant variables. Here the strategy is mainly based on the mushy zone, where the transport of solute is essential, and on the dynamic boundary layer zone in front of the solidification front. So the first step of this strategy is to identify these areas and to calculate the needed mesh size. The objective local mesh size h is determined by three criteria for mushy and liquid areas:

-Gradient of liquid fraction l g ∇ -Gradient of mean concentration w ∇ -Gradient of the velocity norm V ∇ For each parameter, two threshold values and two corresponding mesh sizes are defined, and linear interpolation is made between these points: The mesh size in solid area is calculated by a maximum change in mean concentration in the element. Then the objective mesh size is the minimum of the three values obtained using the three different criteria. Using this strategy we obtain an objective mesh size at each node that combines the information coming from resolution of energy, solute and momentum equations. In the second step the anisotropy factors are calculated. The local anisotropy factors are the orientation of the mesh and the elongation factor. The first one controls the direction in which the objective mesh size is applied and the second one determines the objective mesh size in the two other directions. The domain is divided in three different areas:

( )        < ≥ ≥ + - ⋅ - - > = 1 1 1 2 2 2 1 1 2 2 2 2 if if if S V h S V S h h h S S V S S V
-the solid zone, controled by the mean concentration gradient; -the mushy zone, controled by the liquid fraction gradient; -the liquid zone, controled by the velocity. So, in each zone, the mesh orientation is given by a selected vector (e.g. liquid fraction gradient in the mushy zone). Then the elongation factor is calculated using the direction change of these vectors in the element. The smaller the angle is (e.g. unidirectional flow), the larger the elongation of the element is. Finally the objective metric is smoothed to regularize the mesh sizes before generating a new mesh. This adaptive anisotropic remeshing allows us to refine the mesh in critical areas and is also easy to implement and to adjust to particular cases. Its efficiency has been proved for a simple benchmark case and for a medium ingot case (see ref. [START_REF] Gouttebroze | Modélisation 3D par éléments finis de la macroségrégation lors de la solidification d'alliages binaries[END_REF]). The above description corresponds to THERCAST strategy but R2SOL remeshing module follows the same lines.

Applications

Hebditch and Hunt Test. The first case consists of the solidification of Pb-48wt%Sn and Sn-5wt%Pb ingots studied by Hebditch and Hunt [START_REF] Hebditch | Observations of ingot macrosegregation on model systems[END_REF]. In this test, the alloy is solidified in a parallelepipedic cavity (6 cm high, 10 cm long and 1.3 cm thick, see fig. 2), which is insulated on all surfaces except the thinnest lateral one. This test has already served as a benchmark to evaluate the results of 2D and 3D solidification codes [START_REF] Ahmad | Numerical Simulation of Macrosegregation: a Comparison between Finite Volume Method and Finite Element Method Predictions and a Confrontation with Experiments[END_REF][START_REF] Bellet | A 3D-FEM model solving thermomechanics and macrosegregation in binary alloys solidification[END_REF]. Here it is studied with the 2D codes R2SOL and SOLID, and with the 3D code THERCAST, but using a pseudo-2D (one layer of 3D elements). In this case, we assume that the fluid flow in the largest midplane section is not influenced by the two parallel walls of the cavity. This hypothesis will be demonstrated by the full 3D simulation with THERCAST. The physical data used in the calculation can be found in the literature [START_REF] Ahmad | Numerical Simulation of Macrosegregation: a Comparison between Finite Volume Method and Finite Element Method Predictions and a Confrontation with Experiments[END_REF]. Sn-5wt%Pb Alloy. The computation is performed applying the adaptive remeshing strategy for the R2SOL simulation and a structured fixed mesh for SOLID and THERCAST simulation. The mesh used in THERCAST is 3D with a symmetry plane to simulate just the half of the cavity. The mesh is refined near the back wall and in the channel on the bottom. A constant time step of 0.05 s is used, which is the same as in SOLID. The differences between the codes are shown in fig. 3. The prediction of the channel is effective in each simulation but the application of the remeshing strategy with R2SOL increases the extent of the segregated channels, compared with THERCAST (for more details see [START_REF] Liu | Finite element modelling of macrosegregation and thermomechnanical phenonmena in solidification processes[END_REF]). Assuming a sticking condition at the wall, fig. 3-d) demonstrates that the segregation is really 2D with the formation of segregated bands in the whole width of the cavity. The boundary layer at the wall has a negligible effect on the segregation. So, in this case, a 2D simulation is a good approximation. The adaptive remeshing strategy is applied using a minimum mesh size of 1 mm in the mushy zone and a maximum mesh size equal to 30 mm in the solid zone. For this case the comparison is made only between R2SOL and SOLID because of the huge calculation time needed for a sufficiently fine mesh in 3D.

The numerical gap between a small cavity and a large ingot is really important for FE codes. Actually it seems necessary to maintain a small element size in the mushy zone so a huge mesh must be used without adaptive remeshing. On the contrary the finite volume seems to react differently and a classical mesh, with a smaller number of nodes, is sufficient (this conclusion was also drawn from test on H-H cavity). But the predictions of macrosegregation present some discrepancies as shown on fig. 6. A positive segregation appears in the bottom in R2SOL simulation and also at the level of the refractory part. The axial segregation has the same shape but with higher maximum and minimum values in R2SOL simulation.

To conclude this comparison, it is currently difficult to discriminate the results and decide which code gives the best results. A deeper study of the ingot solidification, of the flow field evolution and formation of macrosegregation along time is certainly necessary to identify the key points of these differences. But the use of adaptive remeshing in R2SOL makes us able to simulate efficiently the macrosegregation and so to obtain crucial information on this process.

Conclusion

After a first implementation of the macrosegregation in the two codes R2SOL and THERCAST, another step has been made by the introduction of a remeshing strategy. The improvement in the results was demonstrated in small cavity and also in a large ingot. But the solidification in large ingot needs more investigation to understand the flow complexity and its coupling with the macrosegregation. Future work will be dedicated to deeper investigations regarding remeshing influence, to the extension to multiconstituent alloys and to the application to industrial castings for sensibility studies.

1 )→ 2 )→ 3 ) 4 )Box 1 .

 12341 Resolution of energy conservation (weak form of (8)) * H Resolution of solute average conservation (weak form of (7)) * w Local resolution, at each node, of microsegregation ((1), (2) and (9)) Resolution of momentum conservation (weak form of (4) or (5)) * V → , * p 5) If full coupling, iterate steps 1) to 4) until convergence. At the end, assign: Summary of the main procedures carried out during a time increment.

Figure 1 .

 1 Figure 1. Evolution of the mesh with the selected criterion value

Figure 2 .

 2 Figure 2. Hebditch and Hunt test problem.

  n=h(T-T ext )

Figure 3 .Figure 4 .

 34 Figure 3. Relative variation of Pb average concentration at 400s: a) with SOLID, b) with R2SOL, c) with THERCAST, d) THERCAST results on a section at z=5mm.

Figure 5 .

 5 Figure 5. Materials properties and boundary conditions for the benchmark ingot simulation.

Figure 6 .

 6 Figure 6. Macrosegregation pattern and axial segregation at the end of the solidification.

Acknowledgement

This work has been supported by the French Ministry of Industry, the French Technical Center of Casting Industries (CTIF) and the companies Arcelor-Irsid, Ascometal, Fonderie Atlantique Industrie, Aubert & Duval Alliages, Erasteel, Industeel and PSA.


Michel Bellet
email: michel.bellet@ensmp.fr

Two-Phase Multiscale FEM Modelling of Macrosegregation Formation in Steel Slabs

Keywords: solidification, mushy zone, 2-phase, thermomechanics, continuous casting, soft reduction PACS:

The conservation equations of a coupled thermomechanical -solute transport model to be applied in mushy zones are first recalled. Then the numerical implementation is discussed, in the context of steel continuous casting modeling. Application to the study of the end of solidification is then considered and the effects of soft reduction process are discussed.

INTRODUCTION

The understanding and control of central macrosegregation in steel continuous casting (CC) is still -after more than 35 years of process development -a major challenge for industry, especially in view of new high strength grades with higher concentrations of alloy elements. In the context of CC, Miyazawa & Schwerdtfeger [START_REF] Miyazawa | Macrosegregation in continuously cast steel slabs: preliminary theoretical investigation on the effect of steady state bulging[END_REF], and Lesoult & Sella [START_REF] Lesoult | Analysis and prevention of centreline segregation during continuous casting of steel related to deformation of the solid phase[END_REF] have demonstrated that macro-segregation in this case highly depends on the deformation of the coherent solid phase in the mushy zone (induced by the bulging between rolls). Following those pioneer works, Kajitani et al. [START_REF] Kajitani | Numerical simulation of deformation induced segregation in continuous casting of steel[END_REF] proposed a numerical model, but doing strong assumptions on the solid phase motion. In previous papers [START_REF] Bellet | A two-phase twodimensional finite element thermomechanics and macrosegregation model of mushy zone. Application to continuous casting[END_REF][START_REF] Fachinotti | Two-phase thermo-mechanical and macrosegregation modelling of binary alloys solidification with emphasis on the secondary cooling stage of steel slab continuous casting processes[END_REF], we have derived a multiscale coupled model for thermomechanical-solute interaction in mushy zones, using spatial averaging on a representative elementary volume of the mushy material. The governing equations of this model are briefly reminded here. Then, its application to the context of CC-modeling is discussed, especially the concurrent modeling of the mushy core and the solid crust of the slab. Finally, an application is presented, including a discussion of the results obtained with and without soft reduction process.

MACROSCOPIC TWO-PHASE MODEL Governing Equations. Multiscale Approach by Spatial Averaging

At the microscopic scale, inside each phase (liquid and solid), the thermo-mechanical evolution is assumed to be governed by the usual mass, momentum energy and solute balances. In this work, the balance equations of the mixture, at the macroscopic scale of a representative elementary volume (REV), are obtained using the spatial averaging method (see [START_REF] Ni | A volume-averaged two-phase model for transport phenomena during solidification[END_REF][START_REF] Rappaz | Numerical modelling in materials science and engineering[END_REF] for details and notations). The solidifying alloy in the mushy state is considered as a saturated two-phase medium (

1 = + l s g g
). Applying the averaging process to microscopic balance equations in each phase k (k = s, l), the following equations (1) are obtained, in which ρ denotes the density, v the velocity field, σ the stress tensor, g the gravity vector, h the enthalpy per unit of mass, q the heat flow vector, c the volume concentration, j the solute flow vector. The terms Γ, M, Q and J are associated with the exchanges of mass, momentum, energy and solute, respectively, between the two phases.

Mass

k k k k k k g g t Γ = ⋅ ∇ + ∂ ∂ ) ( ) ( v ρ ρ Momentum ( ) k k k k k k k k k k k k g g t g g v v v g M σ × ⋅ ∇ + ∂ ∂ = + + ⋅ ∇ ρ ρ ρ ) ( ) ( Energy ( ) ( ) k k k k k k k k k Q h g h g t = ⋅ ∇ + ⋅ ∇ + ∂ ∂ q v ρ ρ Solute ( ) ( ) k k k k k k k J c g c g t = ⋅ ∇ + ⋅ ∇ + ∂ ∂ j v (1)

Hypotheses and Resulting Macroscopic Equations

• The assumption of local thermal equilibrium holds within the REV:

T T T l s = = .
• The solid and liquid phases have constant (but different) densities, in the solidification interval. Solidification shrinkage is then accounted for. • At the microscopic scale, the liquid metal is considered as an incompressible Newtonian fluid. • At the microscopic scale, the solid phase is considered as a non-Newtonian generalized fluid, obeying a Norton-Hoff constitutive equation (degree m power-law). • At the macroscopic scale, a Fick's law is assumed for diffusion in the liquid, while diffusion is neglected in the solid. • The momentum interaction between solid and liquid phases obeys an isotropic Darcy law. Given those hypotheses, the following set of conservation equations is obtained [START_REF] Fachinotti | Two-phase thermo-mechanical and macrosegregation modelling of binary alloys solidification with emphasis on the secondary cooling stage of steel slab continuous casting processes[END_REF]:

Solid momentum ( ) ( ) s s s s s s s s s s l l l l s s g g t g µ g p g v v v g v v Σ × ⋅ ∇ + ∂ ∂ = + - Κ + ∇ - ⋅ ∇ - ρ ρ ρ ) ( 1 2 Liquid momentum ( ) ( ) l l l l l l l l l s l l l l l l g g t g µ g p g v v v g v v s × ⋅ ∇ + ∂ ∂ = + - Κ - ∇ - ⋅ ∇ - ρ ρ ρ ) ( 1 2 Mixture mass t g g g s s l s l l s l s s ∂ ∂ - = ⋅ ∇ + ⋅ ∇ ρ ρ ρ ρ ρ ) ( ) ( v v Mixture energy ( ) 0 ) ( ) ( = ∇ ⋅ ∇ - - ⋅ ∇ + ⋅ ∇ + ∂ ∂ T f f L h t h s l l s λ ρ ρ ρ v v v Mixture solute 0 ) ( )) ( ( ) ( = ∇ ⋅ ∇ - - ⋅ ∇ + ⋅ ∇ + ∂ ∂ l l l s l l l s c D g c g c t c v v v (2)
In those equations, the Darcy terms appear clearly, the permeability Κ deriving directly from the liquid fraction and a predefined secondary dendrite arm spacing (Carman-Kozeny model).

Regarding constitutive models, like Ganesan & Poirier [START_REF] Ganesan | Conservation of mass and momentum for the flow of interdendritic liquid during solidification[END_REF] and Rappaz et al. [START_REF] Rappaz | Numerical modelling in materials science and engineering[END_REF], the average deviatoric stress tensor in the liquid phase is expressed by: ( )

      - = = = )) ( tr( 3 1 ) ( 2 ) ( dev 2 l l l l l l l l l g g v ε v ε v ε s Σ & & & µ µ (3)
For solid, the effective macroscopic stress tensor

I σ Σ l s p + =
can be shown to be a degree m homogeneous function with respect to the strain rate tensor

) ( s s v ε ε & & =
. Adopting a compressible viscoplastic potential, we have [START_REF] Fachinotti | Two-phase thermo-mechanical and macrosegregation modelling of binary alloys solidification with emphasis on the secondary cooling stage of steel slab continuous casting processes[END_REF]:

              - + = - I ε ε Σ s s m s eq s A B A ε K & & & tr 3 1 9 1 1 ) 3 ( 3 1 (4)
in which the two rheological functions A and B depend on the solid volume fraction, according to various models and the equivalent strain rate is expressed as:

( ) 2 2 tr 3 1 9 1 : 1 s s s s eq A B A ε ε ε & & & &       - + = ε (5)
Note also that in energy and solute equations (2d) and (2e), there are specific terms arising from the compression or dilatation of the solid phase.

Microsegregation Model (Solute Exchange at Micro-Scale)

The solute exchange between the solid and liquid phase is governed by interfacial phenomena occurring at the scale of dendrite arms. This is a non-equilibrium process involving complex physics. However, several simplifying hypotheses are allowed in the context of macrosegregation studies. Besides the uniformity of temperature within the REV, both phases are assumed to be at thermodynamic equilibrium at their interface, according to the alloy phase diagram. Then, the interfacial alloy concentrations satisfy: , can be determined from the phase diagram. In this study, both k and the slope of the liquidus line T ∂ ∂ψ are assumed constant. Further, we assume a perfect diffusion of solute in the liquid and in the solid phase at the microscopic scale, so that we obtain:

l m l l l c T T T c k g g c 1 ) ) 1 ( ( -       ∂ ∂ + = - + = ψ ( 7
)
where T m is the fusion temperature of the pure substance and L is the specific latent heat. Keeping in mind the expression of the average specific enthalpy,

L g g g d c h s l l l l l T T p ρ ρ ρ τ τ ) 1 ( ) ( 0 - + + = ∫ (8)
it can be seen that given c and h , ( 7) and ( 8) form a non-linear set of three equations from which the values

s l l c c T g , , ,
can be calculated.

Numerical Implementation

The above equations are solved by a twodimensional finite element method. Hence they are treated in a weak (i.e. integral) form. For CC application, inertia terms are neglected in solid and liquid momentum equations, because of low solid and liquid velocities.

Weak Form of the Mechanical Problem

As shown in next section, the calculation domain encompasses fully solidified regions and coherent mushy zones. Therefore, during the finite element assembly procedure, we treat differently fully solid and mushy finite elements (according to the temperature at element centre).

In the case of a mushy element, its contributions to the residues to be assembled are as indicated in [START_REF] Bellet | A two-dimensional finite element thermomechanical approach to a global stressstrain analysis of steel continuous casting[END_REF] for conservation of solid momentum, liquid momentum and mass (u * , v * and p * being test functions).

In the case of a fully solid element, the expressions of those residue contributions are as indicated in (10).

Mushy Element:

∫ ∫ ∫ ∫ ∫ Ω Ω ∂ Ω - Ω Ω ⋅ - ⋅ - ⋅ - Κ - ⋅ ∇ - ∇ = elt elt elt elt elt s s s s l l l s l s elt sol g g g p * * * 1 2 * * ) ( ) ( : u g u n σ u v v u u Σ R ρ µ ∫ ∫ ∫ ∫ ∫ Ω Ω ∂ Ω - Ω Ω ⋅ - ⋅ - ⋅ - Κ + ⋅ ∇ - ∇ = elt elt elt elt elt l l l s l l l l l l elt liq g g g p * * * 1 2 * * ) ( ) ( : v g v n σ v v v v v s R ρ µ ( ) ( ) ∫ Ω         - ∂ ∂ - ⋅ ∇ + ⋅ ∇ - = elt s l s s l l s l s s elt mass t g g g p ρ ρ ρ ρ ρ v v R * (9) Full Solid Element: ∫ ∫ ∫ ∫ ∫ Ω Ω ∂ Ω - Ω Ω ⋅ - ⋅ - ⋅ - Κ - ⋅ ∇ - ∇ = elt elt elt elt elt s s l l l elt sol g p * * * 1 2 * * ) ( : u g u σn u v v u u s R ρ µ ∫ Ω - ⋅ - Κ = elt s l l l elt liq g * 1 2 ) ( v v v R µ ∫ Ω         + ⋅ ∇ - = elt t p s s s elt mass d d 1 * ρ ρ v R (10)
It can be noted that in the fully solid regions the liquid velocity is still present, but has no real physical meaning: it is kept close to the solid velocity field by means of the sole Darcy term in the liquid momentum equation, acting as a penalty term. The deviatoric stress tensor s is expressed as a function of the velocity field by the viscoplastic Norton-Hoff power law. The material is quasi-incompressible (note the difference between (9c) and (10c): only thermal dilatation terms appear in the contribution to mass conservation.

The integrals in ( 9) and (10) are spatially discretized using P1+/P1+/P1 triangle elements [START_REF] Fachinotti | Two-phase thermo-mechanical and macrosegregation modelling of binary alloys solidification with emphasis on the secondary cooling stage of steel slab continuous casting processes[END_REF], using bubble-type additional interpolation functions for liquid and solid velocities, the pressure being linear and continuous. Their assembly yields a non-linear set of equations to be solved for nodal values of liquid and solid velocities, and pressure (5 unknowns per node in 2D). After resolution, the finite element mesh is updated using the solid velocity: for each node m,

m s m msh m msh m t m t t t v v v x x = ∆ + = ∆ + with ( 11
)
Weak Forms of Thermal and Solutal Problems

The partial time derivative of the enthalpy appearing in (2d) is decomposed into a time derivative with respect to the mesh, moving at velocity s v , and an advection term (a similar transformation is done in the solute equation). The residues to be assembled are as indicated in (12) and the resulting non-linear equations are solved for the nodal values of the average specific enthalpy h . Similarly, (13) gives the expression of the contributions to the solutal residues.The resulting non-linear equations are solved for the nodal values of the average concentration c .

After solidification, those values have null prescribed variations. Integrals in ( 12) and (13) are discretized using P1 triangles.

( ) ( ) ∫ ∫ ∫ ∫ ∫ Ω Ω ∂ Ω Ω Ω - ⋅ ∇ + - ∇ ⋅ ∇ + - ⋅ ∇ + ∂ ∂ = elt elt elt elt elt s l l s s msh elt ther f f L T T h t h R ϕ ρ ϕ φ ϕ λ ϕ ρ ρ ϕ ρ ) ( ) ( v v v v (12) ∫ ∫ ∫ ∫ ∫ Ω Ω ∂ Ω Ω Ω ∇ ⋅ ∇ + ⋅ ∇ - - ⋅ ∇ + ⋅ ∇ + ∂ ∂ = elt elt elt elt elt l l l l l l s l l l s msh elt slte c D g c D g c g c t c R ϕ ϕ ϕ ϕ ϕ n v v v )) ( ( (13)

Roll stand 84

At each time increment, the successive problems are solved in a staggered scheme: i) energy conservation (global solution); ii) solute conservation (global solution); iii) microsegregation (local solution -lever ruleat each node); iv) momentum conservation (liquid and solid) and mass conservation (global solution).

APPLICATION TO STEEL CONTINUOUS CASTING

The material is modeled as a binary Fe-0.18wt%C alloy. The casting velocity is 0.9 m/min and the product thickness is 222 mm. In order to apply the two-phase formulation to a coherent mushy zone, we proceed in two steps. In a first step, a simpler thermomechanical analysis is performed, using a model in which the mushy material is considered as a non-Newtonian fluid, without distinction between solid and liquid velocity fields [START_REF] Bellet | A two-dimensional finite element thermomechanical approach to a global stressstrain analysis of steel continuous casting[END_REF]. From this first calculation, we extract the initial and boundary conditions that are applied to a second calculation performed with the present effective 2-phase model. The data transfer is illustrated in Fig. 1.

From step 1 calculation, we can determine at which depth in the machine the mushy core is fully coherent, i.e. when the solid fraction is greater than 0.65, typically. We initialize then the two-phase calculation starting from this section. The computational mesh grows at the casting speed, starting from a small mesh that also serves as a buffer in the simulation. Along the inlet section of this buffer, the profiles of average enthalpy, normal stress and cumulated plastic strain (in full solid) are imposed. In addition, a uniform nominal solute concentration is assumed, expressing the hypothesis that no segregation has formed yet.

The progress of solidification in the strand is illustrated in Fig. 2. At this stage, the computational domain is 3.5 m long and contains 29000 nodes.

Two different calculations have been carried out. A first one in which the thickness of the strand is kept constant A second one in which this thickness is slightly reduced, as illustrated schematically in Fig. 3. The squeezing ratio of this so-called "soft reduction" process is 1 mm/m. In Fig. 4 and 5 are plotted the axial profiles of liquid fraction and liquid pressure in both cases. It can be seen that the squeezing effect has a minor effect on the advancement of solidification, causing a very slight acceleration of the solidification. The effect is more pronounced on the liquid fraction, which -as expected -is significantly increased in the case of soft reduction. It can be noticed that a constant strand thickness results in large negative values of liquid pressure. In that case (which is not realistic), the shrinkage and dilatation effects are not balanced by any strand reduction: the calculation shows an obvious risk of internal porosity. The consequence of soft reduction on macrosegregation is illustrated in Fig. 6. As expected, the squeezing effect produces a decrease in the positive macrosegregation. It can be seen that the maximum relative macrosegregation which is about 0.162/0.150 = +8% in the standard process (such a ratio agrees with industrial measurements), is reduced to 0.158/0.150 = +5% using soft reduction.

CONCLUSION

The coupled macroscopic thermal-mechanicalsolutal conservation equations for a two-phase continuum have been briefly reminded. A twodimensional finite element solution has been proposed and applied to the context of solidification end in slab-CC. The qualitative response of the model is quite encouraging. Further improvements, including a multiconstituent microsegregation model and more accurate constitutive parameters should result in a predictive tool to be applied to process design.

  where the thermo-dependent partition coefficient k, as well as the equation of the liquidus line ) (T ψ

FIGURE 1 .

 1 FIGURE 1. Two-step strategy for studying the end of solidification with the present model.

FIGURE 2 .

 2 FIGURE 2. Distribution of liquid fraction. Solidification ends 23.5 m below the meniscus, in roll stand 84.

FIGURE 3 .

 3 FIGURE 3. Schematic of the soft reduction process studied.

FIGURE 4 . 5 FIGURE 5 .

 455 FIGURE 4. Axial distribution of liquid fraction, without and with soft reduction process.

FIGURE 6 .

 6 FIGURE 6. Distribution of the average mass concentration of solute w across slab thickness in stand 86, after complete solidification, with and without soft reduction process.

distance to meniscus [m] liquid volume fraction gl [-]

ACKNOWLEDGMENTS

The support of Arcelor Research SA (Arcelor-Mittal group) is gratefully acknowledged.