Changes in opm-models 2019.10 (formerly known as ewoms)
=====================================================

- The module has been renamed to opm-models and some files
  have been moved to opm-simulators.
  - namspace Ewoms renamed to Opm.
  - header directories renamed (ewoms/models->opm/models,
    ewoms/io->opm/models/io, ewoms/linear->opm/models/linear,
    ewoms/common->opm/models/utils,
    ewoms/disc->opm/models/discretization)
    parts of ewoms/linear moved to opm-simulators
    (opm/simulators/linalg) 
- Removed usage and dependency on libecl
- Added support for ROCKCOMP
- Added support for one phase simulations
- Added support for DUNE 2.7.0
- Added experimental foam module.
- Various bugfixes and improvements (polymer, time stepping, dim/dim
  world, parameter system, maximum oil saturations)
  
Changes in eWoms 2018.10
========================

- Major improvements to the parameter system:
  - Support for positional command line parameters.
  - Possibility to hide parameters in the usage message. This is
    useful if parameters are there but not actually used, as is the
    case for some parameters of the `flow` simulator from opm-simulators.
  - The `Dune::ParameterTreeParser` class has been replaced by custom
    code. The rationale is that this allows to use the same syntax for
    parameters in INI-style files as for command line arguments.
  - Better formating of the usage message with more sophisticated handling
    of line breaks.
  - The default values of parameters are now printed in the usage
    message and when outputting the list of parameters.
- Various ebos improvements:
  - The update procedure for Newton-Raphson iterations of the blackoil
    model has been significantly improved.
  - Improvements to the handling of wells: It is now possible to
    specify the well model externally -- i.e., from `flow` -- yet let
    the object be completely managed by `ebos`.
  - Better support for restarts from ECL-formatted files.
  - Support to specify the input deck as a positional parameter and
    only using the name of the deck instead of the complete filename,
    e.g., the command

      ebos SPE1

    instead of

      ebos --ecl-deck-filename=SPE1.DATA

    is now valid.
  - Printing of fluid-in-place (FIP) results can now be forced to be
    suppressed using a command line parameter even if they are
    requested by the deck. This can significantly reduce visual noise
    during development.
  - Various smaller bugfixes and improvements.
- Better support for Schur complements. This feature is already useful
  but it is not yet complete.
- Support for writing VTK output asynchronously (in most cases).
- Performance improvements in the VTK output writing code.
- Introduction of the BEGIN_PROPERTIES and END_PROPERTIES macros in
  the property system: This avoids having to explicitly specify the
  namespace where properties are located. Usage of these macros is
  currently completely optional.
- The compositional model based on non-linear complementarity problems
  (NCP) now works in conjunction with adaptive grid refinement.
- Various minor fixes and improvements.

Changes in eWoms 2018.04
========================

- Significant improvements to the black-oil flow model and to ebos,
  the Ecl Black-Oil Simulator:
  - An extension for energy conservation similar to the "solvent" and
    "polymer" extensions was added to the black-oil model
  - The DRSDT and DRVDT keywords are now implemented and fully
    supported by ebos
  - The ECL output writing code has been overhauled and now uses the
    infrastructure from opm-common instead of calling libecl directly.
  - The code for computing hydrostatic equilibrium for the initial
    condition has been moved in from opm-core and cleaned up.
- The "GridManager" classes have been renamed to "Vanguard".
- "Tasklets", an asynchronous work execution mechanism, have been added
  and are used to write VTK and ECL output without blocking the main
  thread.
- The boundary condition handling has been refactored: Instead of
  assuming a "minimal" fluid state with only fluid pressures,
  temperatures and saturations defined, the boundary code now assumes
  that all quantities of the passed fluid state are defined. In
  particular, this means that fluid viscosities, densities and
  enthalpies can no longer be left undefined for boundary fluid
  states.
- Handling thermal conduction and heat capacity of the solid matrix
  has been overhauled in step with opm-material.
- eWoms is now compatible with DUNE 2.6 and the latest DUNE
  development version of 2.7. The minimum required DUNE version stays
  DUNE 2.4.
- Building eWoms without the opm-common module is now possible if the
  alternative build system as described in the INSTALL file is
  used. In this case, ebos is unavailable.
- Many smaller bug fixes and cleanups


Changes in eWoms 2017.10
========================

- Many improvements to the black-oil flow model and to ebos, the Ecl
  Black-Oil Simulator:
  - Fixes for several parallelization issues
  - Improved performance for two-phase runs
  - Possibility to simulate gas-oil cases in addition to oil-water
    cases
  - Overhauled primary variable switching logic
  - Implementation of solvent and polymer extensions
  - Option to conserve surface volume of the fluids instead of
    component mass
- The vertex centered finite volume discretization now works with
  automatic differentiation
- The model for the Stokes equations has been removed: This model
  never worked well and was very prone to breakdowns and numerical
  oscillations
- The minimum version of DUNE is now 2.4
- The C++ compiler is now assumed to be fully C++-2011 compliant. GCC
  >= 4.8.2 and clang > 3.3 should work
- Many smaller bug fixes and cleanups

Changes in eWoms 2017.04
========================

- Re-implementation of the BiCGSTAB linear solver to avoid potential
  copyright issues with dune-istl while retaining the performance
  improvement due to custom convergence criteria.
- Support for using a different floating point precision in the linear
  solver than in the linearization.
- Various cleanups in the linear solver backends.
- Various changes in ebos to use it as an upstream framework. These
  are primarily motivated by flow_ebos, a new simulator for ECL
  problems that is part of the opm-simulators module.
- Support for passing the transmissibilities as edge weights for
  partitioning the grid in ebos.
- Support for two-phase blackoil simulations.
- Support for explicit prefetching and addition of PffGridVector, a
  prefetch-friendly container class.
- Better support for non-Linux unix systems like MacOS X.
- Many bugfixes all over the place.

Changes in eWoms 2016.04 and eWoms 2016.10
==========================================

- Support for Dune 2.2 has been removed: Dune 2.3 has been released in
  February 2014, so it should be old enough to be available everywhere
  where the latest eWoms release is supposed to be used.
- Support for the legacy ALUGrid Dune grid provided by old versions of
  the dune-grid module has been removed. the stand-alone dune-alugrid
  module can be used as a drop-in replacement.
- The Navier-Stokes test has been removed: It did not work properly
  and earlier releases of eWoms just hid the issues.
- The dune-localfunctions module is now an optional instead of a
  required dependency. If it is not available, the vertex-centered
  finite volume method (VCFV) cannot be used with P1 finite element
  gradients, i.e., it only supports two-point gradients in that case.
- An explicitly as an optional dependency has been added on opm-parser
  module. So far, the opm-parser dependency was implicitly inherited
  from the optional opm-grid module.
- Many improvements of ebos (the Ecl Black-Oil Simulator):
 - Treatment of wells can be completely disabled at compile time. This
   is useful if eWoms is used as a simulation framework and an
   external well model shall be used ECL simulations.
 - Consistent determination of the upstream direction: So far, it was
   possible that the upstream direction differed depending on which
   side an intersection was used if the pressure gradient over the
   intersection was zero.
 - The calculated transmissibilities and threshold pressures are now
   the same as those calculated by the `flow` simulator from
   opm-autodiff.
 - Support for the VAPPARS keyword.
 - Proper support for specifying the pore volume directly (using the
   ECL "PORV" keyword), minimum pore volume ("MINPV") and the most
   common pore volume modifier keywords ("NGT", "MULTPV" and
   "MULTREGP")
 - Support for simple geology changes during the simulation, e.g., the
   "MULTFLT" keyword can now occur in the "SCHEDULE" section.
- Support for caching the initial storage term of time steps for
  better performance.
- Support for lockless multithreaded linearization. This code only
  works for spatial discretizations that guarantee that the
  linearization for a degree of freedom is only written to by a single
  thread. Most prominently, this property holds for the element
  centered finite volume discretization (ECFV).
- Improvements to the update procedure of the Newton-Raphson method:
  In particular, a linearized system of of equations does not need to
  be solved anymore if the solution is deemed to be converged.
- The residual of the "phase presence" equations is not considered for
  convergence by the NCP model anymore. This should make the behavior
  of the NCP model identical to that exhibited by the PVS model.
- Many minor bugfixes and improvements.


Notable Differences Between eWoms 2015.04 and eWoms 2015.10
===========================================================

- An automatic differentiation framework has been added. Compared to
  the default linearization method (i.e., finite differences)
  automatic differentiation is about 20% faster and is also slightly
  more accurate. Due to technical reasons, it can only be used with
  the element-centered finite volume discretization (ECFV) at the
  moment. Automatic differentiation can be used by adding the line

  SET_TAG_PROP(YourProblemTypeTag, LocalLinearizerSplice, AutoDiffLocalLinearizer);

  to the problem file.
- The ECL material relations have received a significant
  overhaul. Advanced features like end-point scaling and
  runtime-selectable saturation functions are now supported.
- The ECL Black-Oil Simulator (ebos) has received many bug fixes and
  new features. Amongst others, it now uses automatic differentiation,
  supports specififying the the steady-state of the reservoir as
  initial condition (using the EQUIL) keyword and it supports scenarios
  involving wet-gas and dry-oil.

Notable Differences Between eWoms 2013.10 and eWoms 2015.04
===========================================================

- The eWoms property system now supports "splices", a mechanism for
  "deferred inheritance": It allows to specify the type tags from
  which a base type tag derives from at a later time. A typical
  use-case for this functionality is to specify the spatial
  discretization which is be used at the problem level instead of for
  the type tag of the physical model.
- eWoms now supports multiple spatial discretizations. So far, only an
  element-centered finite volume method has been implemented.

  To specify that a problem should use the element-centered finite volume
  discretization, include the file "ewoms/disc/ecfv/ecfvdiscretization.hh"
  and set the "SpatialDiscretizationSplice" property to
  "EcfvDiscretization". The latter is achieved by adding the line

  SET_TAG_PROP(YourProblemTypeTag, SpatialDiscretizationSplice, EcfvDiscretization);

  to your problem file.
- ebos, a fully-implicit black oil simulator for datasets specified
  using the ECL data format, has been added. The results for various
  widely used benchmark datasets (i.e., SPE-1, SPE-3 and SPE-9) are
  very similar to the ones produced by the commercial standard
  simulator which is used by the crude oil industry.
- Stability, performance and consistency improvements across the
  board.

Notable Differences Between eWoms 2.3 and eWoms 2013.10
=======================================================

- The semi implicit ("decoupled", "IMPET") models have been removed
  due to a lack of interest and the slowly increasing maintenance
  burden as the Dumux and eWoms code bases continue to diverge.
- The custom CMake-based and the autotools based DUNE build systems
  have been removed and replaced by the CMake based build system of
  the Open Porous Media Initiative.
- The material laws framework has evolved into a separate module,
  "opm-material". This means that this module must be also present
  when compiling eWoms.
- The property system has been moved to opm-core, along with some
  support code. As a consequence, all parameters must now be defined
  in the namespace Opm::Properties instead of Ewoms::Properties

Notable Differences Between eWoms 2.2 and eWoms 2.3
===================================================

- The namespace for all eWoms classes has been changed from "Dumux" to
  "Ewoms". This makes it easy to provide distribution packages for
  both, Dumux and eWoms that do not clash. Also, it allows to use
  Dumux and eWoms classes within the same piece of code. Finally, this
  helps to avoid mental confusion when it comes to relation between
  Dumux and eWoms. To adapt your code to the change, you may follow
  the procedure below:

  - MAKE A BACKUP OF YOUR PROJECT. Although the following steps should
    usually work without manual intervention, there might still be
    unforseen problems!
  - Go to the root directory of your project:

     cd $YOUR_PROJECT_ROOT

  - Rename the 'dumux' directory (if existent) to 'ewoms'. If you use
    git for revision control of your project, this should be done
    using

     git mv dumux ewoms

  - Run the following to adapt the contents of the files of your
    project:

     # adapt c++ sources
     find -name "*.hh" -o -name "*.cc" | \
       xargs sed -i "
         s/Dumux::/Ewoms::/g;
         s/namespace Dumux/namespace Ewoms/;
         s/\(include.*\)dumux\(.*\)/\1ewoms\2/;
         s/DUMUX/EWOMS/"
     # adapt the build system
     find -name "Makefile.am" -o -name "configure.ac" | \
       xargs sed -i "s/dumux/ewoms/g"

  - Run dunecontrol for your project and re-compile.
- The property system has received a major overhaul. The benefits of
  this are the possibility to specify type tags with an arbitrary
  number of parents and splices, a mechanism for deferred inheritance.
  The Splices of a type tag can be thought of as ordinary parent
  nodes, but these can be overwritten at a later point. This allows to
  specify things which require specific properties -- like the linear
  solver, spatial and time discretization, etc -- to be specified much
  more easily. So far, splices are only used for the linear solvers,
  but they also will be used to select the spatial and the temporal
  discretization in a modular way. Despite all this, code which only
  uses features officially supported by eWoms 2.2 is expected to work
  without any modifcation.
- The autotools based build system is now non-recursive. This makes
  parallel builds (i.e. running 'make -j$NUM_CORES check' in the
  toplevel directory of the eWoms source code) more efficent. The
  implication is that new tests need to be added to the toplevel
  Makefile.am instead of to the Makefile.am of the directory where the
  test resides.
- The implicit models have been reorganized:
  - Discretizations now reside in the ewoms/disc directory
  - The vertex-centered finite volume discretization has been renamed
    from "box" to "vcfv" to make its name more descriptive and more
    consistent with further discretizations. The names of all
    properties, classes and files which where prefixed by 'Box' are
    now prefixed by 'Vcfv'.
- The decoupled models have been parallelized. No dynamic
  load balancing can be done yet.
- The concept of Newton controllers has been abandoned. The
  functionality previously implemented has been absorbed by the
  NewtonMethod classes which now use static polymorphism. The reason
  for this change is that this makes the Newton solver use the same
  design as used by most of the other parts of eWoms, and that the
  original reason to split the policy from the algorithmic part of the
  Newton method turned out not to be used in practice. (The reason was
  to be able to implement different policies with zero overhead, but
  all implemented Newton controllers were just derived from the default
  NewtonController.) Also, the following properties have been renamed
  during the exercise:
   - NewtonRelTolerance -> NewtonRelativeTolerance
   - NewtonAbsTolerance -> NewtonAbsoluteTolerance
   - NewtonMaxSteps -> NewtonMaxIterations
   - NewtonTargetSteps -> NewtonTargetIterations
   - NewtonMaxRelError -> NewtonMaxRelativeError
   - NewtonSatisfyAbsAndRel -> NewtonSatisfyAbsoluteAndRelative
- A fully-implicit discrete 2D fracture model for two-phase problems has
  been added.
- The header file containing the eWoms parameter system has been
  renamed from "parameters.hh" to "parametersystem.hh" to make it
  consistent with the naming scheme of the property system.
- Control files for creating Debian/Ubuntu packages have been added to
  the git repositories. To build these packages, run 'debuild -us -uc'
  in the top-level directory of the source tree. (This only works for
  Debian or Ubuntu based distributions.)
- A specfile to build packages for redhat distributions (RHEL and
  Fedora) has also been added to the repositories. To build an RPM
  package, run 'rpmbuild -bi redhat/ewoms.spec' in the directory which
  contains the source tree checked out using git. For this, a tarball
  with the sources needs to be located in rpmbuild's SOURCE
  directory. (Note that the release tarballs do neither contain the
  RPM specfiles nor the control files for Debian.)


Notable Differences Between DuMuX 2.1 and eWoms 2.2
===================================================

- The minumim required version of the Dune core modules is now
  2.2. This means that eWoms will no longer compile with Dune 2.1.
- eWoms now compiles with the LLVM-CLang compiler. The minimum version
  required is CLang 3.1.
- Support for compilers that don't support the 'auto' keyword and
  initializer lists has been dropped. As a consequence eWoms will not
  compile with GCC prior to version 4.4.
- The abstractions between problems, flow models, discretization
  schemes and solvers have been overhauled for the fully-implicit models:
  - Problems only specify a given set-up. This means that problems
    usually do not manipulate primary variables or fluxes directly.
  - All "spatial parameters" classes have been merged with their
    respecitve problems. This was done because most methods of the
    problems already specified spatially dependent parameters.
- The API of the problems is not specific to any flow model or spatial
  or temporal discretization anymore. This is achived by passing
  so-called "context objects" and a space and time index to all of the
  problem's methods which are potentially dependent on space or
  time. All context objects provide a generic set of methods
  (e.g. pos() and globalSpaceIdx()), and some discreization specific
  ones. The problems and the physical models are not supposed to know
  what a given space and a time index means.
- The boundary conditions for fully-implicit models are now weakly
  imposed. For this reason, the problem's methods boundaryTypes(),
  dirichlet(), and neumann() are superseded by the method
  boundary(). This method gets an object of the new BoundaryRateVector
  class, which can be used to specify fluxes for a given boundary
  segment. It also provides methods to specify in-flow, out-flow and
  free-flow boundary conditions called setInFlow(), setOutFlow() and
  setFreeFlow() given a fluid state for the boundary segment.
- As a consequence of the previous item, Dirichlet boundary conditions
  are now not implemented as constraint degrees of freedom anymore. If
  the problem requires constraints, the "EnableConstraints" property
  needs to be set to "true" and the problem needs to overload the
  constraints() method. In contrast to the previous implementation,
  eWoms now also supports constraint degrees of freedom in the
  interior of the domain. ("Dirichlet" conditions previously where
  only possible at finite volumes adjacent to the grid boundary.)
- The parameter system has received a major overhaul: “Runtime”
  parameters have been abandoned, as have parameter groups. Runtime
  parameters have bitten the dust because of their flawed semantics
  (all parameters are always specified on run-time), groups where
  removed because they caused confusion when specifying parameters
  from the command line (e.g. the correct way to specify the relative
  tolerance of the Newton solver was ‘—newton.rel-tolerance’ instead
  of ‘—newton-rel-tolerance’). Also, all parameters must now be
  registered using the REGISTER_PARAM macro before they are
  accessed. This allows to print a canonical list with all parameters
  and their description when the program is run with “—help” and also
  allows to print a comprehensive list with the values of all
  parameters at the beginning of a simulation.
- The fully-implicit compositional models 1p2c, 2p2c(ni) and 3p3c(ni)
  are superseeded by the 'pvs' model, a generic model based on primary
  variable switching. The model supports an arbitrary number of fluid
  phases and chemical components, but it still requires that all fluid
  phases are ideal mixtures.
- The fully-implicit multi-phase models which assume immiscibility --
  i.e. 1p and 2p are superseeded by 'immiscible' model which supports
  an arbitrary number of fluid phases.
- A fully-implicit black-oil model and the corresponding fluid system
  has been added. The black-oil model is a three-phase three-component
  paritially miscible model that is widely used in petrolium
  engineering. The black-oil fluid system also allows to use
  full-fledged compositional models (Mp-Nc, 3p3c) to be used with
  black-oil parameters.
- The fully-implicit non-isothermal models (2pni, 2p2cni, 3p3cni,
  stokes2cni) have been replaced by a generic implementation of the
  energy equation. As a consequence, you have to derive your problem's
  type tag from the one of the isothermal model (i.e. BoxNcp, BoxPvs,
  BoxImmisicible or BoxStokes) and set the property ‘EnableEnergy’ to
  true. The latter can be done by adding the following line to the
  problem file:

    SET_BOOL_PROP(YourProblemTypeTag, EnableEnergy, true);

- Many bugs have been shaken out of the code for MPI parallelization
  code. As a result, the fully-implicit models should work much better
  for parallel computations. As a consequence, the parallelization is
  no longer considered experimental.
- Support for using pluggable convergence criteria has been added to
  the linear solvers. The eWoms default criterion now consideres the
  reduction of the weighted maximum defect of the linear system of
  equations instead of the reduction of the two norm of the
  defect. This leads to major performance and stability improvements
  in many cases.
- A back-end for the parallel algebraic multi-grid linear solver
  provided by DUNE-ISTL has been added for the fully implicit finite
  volume models. It is still considered to be slightly experimental
  and it can be used by specifying the property

    SET_TYPE_PROP(ProblemTypeTag, LinearSolver, Dumux::BoxParallelAmgSolver<TypeTag>);

  in the problem file.
- All fully-implicit models now use the generic M-phase material laws
  which (in principle) allow to implement capillary pressure and
  relative permeability relations depending on absolute pressure,
  temperature and phase composition. Also, these material laws do not
  require the flow model to make assumptions on the wettability of
  fluids.
- Heat conduction laws have been introduced. They work analogous to
  the capillary pressure/relative permeability laws.
- The primary variables are not "dumb" vectors anymore, but can also
  store "pseudo primary variables" like the phase state.
- 'Rate vectors' have been introduced. They allow to specify fluxes
  and source terms independent of the underlying flow model and also
  support specifying volumetric rates.
- Writing VTK output files has been centralized. This allows to
  simplify the flow models, and allows much finer granularity over
  what quantities get written to disk. Writing a quantity can be
  enabled by passing e.g. the "--vtk-write-temperature=1" parameter to
  the executable.
- Flow models now specify names for the conservation equations and
  primary variables which they use. This significantly improves the
  comprehensibility of the VTK output when the convergence behaviour of
  the Newton method is written to disk.
- Most physical models now only support a single formulation
  (i.e. choice of primary variables and conservation equations). This
  makes them more readable and improves test coverage. This change was
  motivated by the fact that, since problems can easily be specified
  independent of the flow model, supporting multiple formulations does
  not really make sense anymore.
- A h-adaptive semi-implicit model using an MPFA L-method was
  added. It simulates two-phase and two-phase, two-component flow on
  unstructured grids in two dimensions.  See test/decoupled/2p(2c) for
  an example.

Notable Differences Between DuMuX 2.0 and DuMuX 2.1
===================================================

- The thermodynamics framework has been overhauled:
  - The programming interfaces for fluid systems, fluid states and
    components has been formalized and cleaned up.
  - Fluid systems now have the option to cache computationally
    expensive parameters if they are needed for several relations.
  - Fluid systems are not charged with the computation of the
    chemical equilibrium anymore.
  - Fluid states are now centralized infrastructure instead of being
    model-specific.
  - Constraint solvers (which simplify solving thermodynamic
    constraints) have been introduced.
- Outflow boundary conditions have been implemented for the
  fully-implicit models 1p2c, 2p2c(ni) and stokes(2cni).
- The problem and spatial parameter base classes also provide optional
  model-independent interfaces. These methods only get the position in
  global coordinates as argument and are named *AtPos()
  (e.g. boundaryTypesAtPos()). This allows an easy transfer of problem
  definitions between implicit and sequential models.
- The following fully-implicit models have been added:
  - 3p3c, 3p3cni: Isothermal and non-isothermal three-phase,
    three-component models for flow and transport in porous media
    based on primary variable switching.
  - MpNc: A model for arbitrary number of phases M > 0, and components
    (N >= M - 1 >= 1) for flow and transport in porous media. This
    model also comes with an energy and a molecular diffusion module.
  - stokes, stokes2c, stokes2cni: Models for the plain Stokes
    equation as well as isothermal and non-isothermal Stokes models
    for two-component fluids.
- The sequentially-coupled models have been overhauled:
  - A common structure for cell centered standard finite volume
    implementations has been introduced.
  - The data structures where overhauled to avoid large clumps of data
    in large-scale simulations: Each cell stores data in its own
    storage object.
  - The too large assemble() methods have been split into submethods
    getStorage(), getFlux() etc. By this, inheritance of classes has
    been improved and code duplication was reduced.
  - The conceptual seperation of the "VariableClass" (central
    infrastructure), data storage, transport model and pressure model
    has been improved.
  - More of infrastructure is now shared with the implicit models
    (e.g. the BoundaryTypes). This results in significant performance
    improvements and makes debugging easier.
- The 2padaptive sequentially coupled model has been added. This model
  implements a grid-adaptive finite volume scheme for immiscible
  two-phase flow in porous media on non-conforming quadrilateral
  grids.
- The dependencies for the external dune-pdelab and boost packages
  have been removed.
- The build system has received major improvements:
  - There is now much better test coverage of build-time dependencies
    on packages for the default autotools-based build system.
  - Experimental support for building DuMuX using CMake has been much
    improved. In the long run, CMake is projected to become the
    default build system.
- All headers can now be included without any preconditions.
- DuMuX now compiles without warnings if the -pedantic flag used for GCC.
- Specifying run-time parameters is now possible. The mechanism allows
  to use parameter files or to specify parameters directly on the
  command line and fallback parameter input files have been added for
  each test application.  As a consequence, applications can be run
  now without specifying any command line arguments.
- The DuMuX property system has been fine-tuned:
  - Encapsulating property names with the PTAG() is no longer required
    for the GET_PROP* macros (but is still allowed).
  - Setting property defaults has been deprecated.
  - All properties defined for a type tag can now be printed. Also,
    their value and the location in the source where they where
    specified is included in the output.
- Using quadruple precision math has been made possible for GCC 4.6 or newer:
  - To use it, the configure option '--enable-quad' needs to be added
    and the type of scalar values needs to be changed to 'quad'. This
    can be done in the problem file using

        SET_TYPE_PROP(YourProblemTypeTag, Scalar, quad);

    It should be noted, that performance is very poor when using
    quadruple precision arithmetic. This feature is primarily meant as
    a debugging tool to quickly check whether there are machine
    precision related convergence problems.