LMGC90 Sprint at Logilab

At the end of March 2013, Logilab hosted a sprint on the LMGC90 simulation code
in Paris.

LMGC90 is an open-source software developed at the LMGC ("Laboratoire de
Mécanique et Génie Civil" -- "Mechanics and Civil Engineering Laboratory") of
the CNRS, in Montpellier, France. LMGC90 is devoted to contact mechanics and is,
thus, able to model large collections of deformable or undeformable physical
objects of various shapes, with numerous interaction laws. LMGC90 also allows
for multiphysics coupling.

the LMGC, which leads LMCG90 development and aims at constantly improving its
architecture and usability;

the Innovation and Research Department of the SNCF (the French state-owned
railway company), which uses LMGC90 to study railway mechanics, and more
specifically, the ballast;

the LaMSID ("Laboratoire de Mécanique des Structures Industrielles Durables",
"Laboratory for the Mechanics of Ageing Industrial Structures") laboratory
of the EDF / CNRS / CEA , which has an strong expertise on Code_ASTER
and LMGC90;

Logilab, as the developer, for the SNCF, of a CubicWeb-based platform
dedicated to the simulation data and knowledge management.

After a great introduction to LMGC90 by Frédéric Dubois and some preliminary
discussions, teams were quickly constituted around the common areas of interest.

As of the sprint date, LMGC90 is mainly developed in Fortran, but also contains
Python code for two purposes:

Exposing the Fortran functions and subroutines in the LMGC90 core to Python;
this is achieved using Fortran 2003's ISO_C_BINDING module and Swig.
These Python bindings are grouped in a module called ChiPy.

Making it easy to generate input data (so called "DATBOX" files) using Python.
This is done through a module called Pre_LMGC.

The main drawback of this approach is the double modelling of data that this
architecture implies: once in the core and once in Pre_LMGC.

It was decided to build a unique user-level Python layer on top of ChiPy,
that would be able to build the computational problem description and write the
DATBOX input files (currently achieved by using Pre_LMGC), as well as
to drive the simulation and read the OUTBOX result files (currently by using
direct ChiPy calls).

This task has been met with success, since, in the short time span available
(half a day, basically), the team managed to build some object types using
ChiPy calls and save them into a DATBOX.

This topic involved importing LMGC90 DATBOX data into the numerical platform
developed by Logilab for the SNCF.

This was achieved using ChiPy as a Python API to the Fortran core to get:

the bodies involved in the computation, along with their materials, behaviour
laws (with their associated parameters), geometries (expressed in terms of
zones);

the interactions between these bodies, along with their interaction laws (and
associated parameters, e.g. friction coefficient) and body pair (each
interaction is defined between two bodies);

the interaction groups, which contain interactions that have the same
interaction law.

There is still a lot of work to be done (notably regarding the charges applied
to the bodies), but this is already a great achievement. This could only have
occured in a sprint, were every needed expertise is available:

the SNCF experts were there to clarify the import needs and check the overall
direction;

Logilab implemented a data model based on CubicWeb, and imported the data
using the ChiPy bindings developed on-demand by the LMGC core developer team,
using the usual-for-them ISO_C_BINDING/ Swig Fortran wrapping dance.

Logilab undertook the data import; to this end, it asked the LMGC how the
relevant information from LMGC90 can be exposed to Python via the ChiPy API.

The main point of this topic was to replace the in-house DATBOX/OUTBOX textual
format used by LMGC90 to store input and output data, with an open, standard and
efficient format.

Several formats have been considered, like HDF5, MED and NetCDF4.

MED has been ruled out for the moment, because it lacks the support for storing
body contact information. HDF5 was chosen at last because of the quality of its
Python libraries, h5py and pytables, and the ease of use tools like h5fs provide.

Alain Leufroy from Logilab quickly presented h5py and h5fs usage, and the team
started its work, measuring the performance impact of the storage pattern of
LMGC90 data. This was quickly achieved, as the LMGC experts made it easy to
setup tests of various sizes, and as the Logilab developers managed to
understand the concepts and implement the required code in a fast and agile way.

This topic turned out to be more difficult than initially assessed, mainly
because LMGC90 has dependencies to non-packaged external libraries, which thus had
to be packaged first:

the Matlib linear algebra library, written in C,

the Lapack95 library, which is a Fortran95 interface to the Lapack library.

Logilab kept working on this after the sprint and produced packages that are
currently being tested by the LMGC team. Some changes are expected (for instance,
Python modules should be prefixed with a proper namespace) before the packages can be
submitted for inclusion into Debian. The expertise of Logilab regarding
Debian packaging was of great help for this task. This will hopefully help to
spread the use of LMGC90.

As you may know, Logilab is really fond of Mercurial as a DVCS. Our company
invested a lot into the development of the great evolve extension, which makes
Mercurial a very powerful tool to efficiently manage the team development of
software in a clean fashion.

This is why Logilab presented Mercurial's features and advantages over the
current VCS used to manage LMGC90 sources, namely svn, to the other
participants of the Sprint. This was appreciated and will hopefully benefit to
LMGC90 ease of development and spread among the Open Source community.

All in all, this two-day sprint on LMGC90, involving participants from several
industrial and academic institutions has been a great success. A lot of code has
been written but, more importantly, several stepping stones have been laid, such
as:

the general LMGC90 data access architecture, with the Python layer on top of
the LMGC90 core;