# Release Notes¶

## pyMOR 2021.1 (September 24, 2021)¶

We are proud to announce the release of pyMOR 2021.1! This release includes several new reductors for LTI systems. In particular, methods for reducing and analyzing unstable systems have been added. ANNs can now be used in order to directly approximate output quantities. Furthermore, it is now possible to work with time-dependent parameters in pyMOR.

Over 700 single commits have entered this release. For a full list of changes see here.

pyMOR 2021.1 contains contributions by Tim Keil, Hendrik Kleikamp, Josefine Zeller and Meret Behrens. See here for more details.

### Release highlights¶

#### Methods for unstable LTI systems¶

Many popular system-theoretic model order reduction methods are not applicable
to unstable LTI systems out of the box. In
[#1149] two reductors and several
methods for working with and analyzing unstable `LTIModels`

have been added.
The `FDBTReductor`

allows for applying the balanced
truncation technique to unstable systems by performing a Bernoulli stabilization
before using the classical BT method. The `GapIRKAReductor`

aims to compute a reduced-order model such that the approximation error with
respect to the \(\mathcal{H}_2\)-Gap norm is small. Additionally,
a variety of numerical linear algebra methods have been a part of
[#1149]: Riccati equation solvers
for small and dense matrices, Bernoulli matrix equation solver, new options for
for pyMOR’s eigensolver such as shift-and-invert mode and \(\mathcal{L}_2\)-norm
computation for `LTIModels`

. The new methods and reductors are showcased in
Tutorial: Model order reduction for unstable LTI systems.

#### Modal truncation¶

Based on the previously added `samdp`

method for
computing dominant poles of an LTI system,
a modal truncation reductor `MTReductor`

was added in
[#1151].
It constructs a reduced-order model from dominant poles of the full-order model,
with different possible dominance measures.
The reductor also implements a dense method for small to medium problems.

#### Time-dependent parameter values¶

We have extended the handling of `Parameters`

in pyMOR to allow time-dependent
`parameter values`

. Such parameter values are specified by instantiating a
`Mu`

object with a `Function`

that maps the current
time to the respective parameter value. The function is automatically evaluated
at `mu['t']`

and correspondingly updated in `mu.with_(t=new_time)`

such that
the time dependence of the values is completely transparent to their consumer.
This allows existing ROMs to be used with time-dependent parameter values
without any changes in the MOR algorithm. For further details, see
[#1379].

### Additional new features¶

#### Symbolic ExpressionFunctions¶

A simple symbolic math expression library has been added to pyMOR, which is now
used by `ExpressionFunction`

and `ExpressionParameterFunctional`

to parse and
evaluate the given expressions, see
[#1277]. As immediate benefits,
the `shape`

of the expression is now automatically determined and the expression is
automatically vectorized correctly. In particular, there is no longer a need to
add `...`

to indexing expressions. Further, malformed expressions now lead
to meaningful error messages at parse time.

In the future, conversion routines will be added to make the expression library
usable for `discretizers`

that use external PDE solvers, such that
the same `ExpressionFunction`

can be used for different PDE solver backends.

#### Output reductor using ANNs¶

To further extend the neural network based reductors, in
[#1282] a reductor that only
approximates the mapping from parameter space to output space using a neural
network was added. Furthermore, a corresponding reductor for the instationary
case was implemented. The new reductor for the stationary case is used in
Tutorial: Model order reduction with artificial neural networks and compared to the
`NeuralNetworkReductor`

.

As part of [#1282], the ANN-reductors were refactored, and in [#1274], the neural network training routines have been separated from the reductors.

#### Improvements to the HAPOD algorithm¶

pyMOR’s implementation of the HAPOD algorithm has seen several significant improvements in [#1322]:

`hapod`

now launches its own asyncio event loop in order to avoid conflicts with already running event loops (e.g. when running from jupyter).It is now possible to explicitly specify that a node has to be processed after certain other nodes. In particular, this can be used to ensure the right execution order for incremental POD computations.

HAPOD trees are now created dynamically, which should significantly simplify specifying own tree topologies.

`dist_hapod`

now has an`arity`

argument, which allows to control the number of intermediate POD levels.`inc_hapod`

now accepts arbitrary iterables for the snapshot data, which makes it easy to incrementally compute the data while computing the POD.

#### Improved support for Empirical Interpolation of functions¶

The `ei_greedy`

algorithm has been improved, in
particular to make it more useful for the interpolation of coefficient
`Functions`

. Based on these improvements, an
`interpolate_function`

method has been added which
creates an `EmpiricalInterpolatedFunction`

from an arbitrary pyMOR `Function`

. The `function_ei`

demo script
demonstrates the new functionality. For further details, see
[#1240].

#### Methods for exporting matrices of system models¶

The system classes `LTIModel`

and
`SecondOrderModel`

have had various `from_*`

methods
for constructing models from matrices.
In [#1309],
the corresponding `to_*`

methods were added for exporting matrices from a model.

#### pyMOR is now a pure Python package¶

All Cython modules in pyMOR’s discretization toolkit have been replaced by
equivalent `NumPy`

code, see [#1314].
As a result, pyMOR is now a pure Python package, which should significantly
simplify pyMOR’s installation when no pre-built binary wheels are available.

### Backward incompatible changes¶

#### Drop python 3.6 support¶

Support for Python 3.6 has been dropped in pyMOR 2021.1 [#1302]. The minimum supported version now is Python 3.7.

#### Symbolic ExpressionFunctions¶

Due to the improvements in [#1277],
the signature of `ExpressionFunction`

has changed. To use existing code with
pyMOR 2021.1, the `shape_range`

argument has to be removed from all
instantiations of `ExpressionFunction`

. Further, all occurrences of `...`

have to be removed in indexing expressions.

### Further notable improvements¶

[#1234] [operators/block] skip ZeroOperators in apply and apply_adjoint

[#1243] Fixed computation of intersection_codim in _neighbours

[#1294] Let sample_randomly return a Mu instance in case count=None

[#1317] Add FenicsMatrixOperator._real_apply_inverse_adjoint_one_vector

[#1325] Let MPIOperator.assemble return self when operator is unchanged

[#1327] Use complex vector handling of wrapped object in MPIVectorArray

[#1408] Introduce ListVectorSpace.vector_type and make make_array smarter

## pyMOR 2020.2 (December 10, 2020)¶

We are proud to announce the release of pyMOR 2020.2! This release extends pyMOR’s support for non-intrusive model reduction via artificial neural networks to non-stationary models. Built-in support for computing parameter sensitivities simplifies the use of pyMOR in PDE-constrained optimization applications. pyMOR’s documentation has been extended by three new tutorials, and all tutorial code can now easily be executed using binder.

Over 520 single commits have entered this release. For a full list of changes see here.

pyMOR 2020.2 contains contributions by Tim Keil and Hendrik Kleikamp. See here for more details.

### Release highlights¶

#### Parameter derivatives of solutions and outputs¶

In [#1110] tools for
PDE-constrained parameter optimization were added. These include parameter derivatives
of the solutions and the output of a `Model`

. In particular,
`solve_d_mu`

can now be used to compute partial
parameter derivatives. Moreover, `output_d_mu`

can be used to compute the parameter gradient of the output using the
derivatives of the solutions. Alternatively, for a `StationaryModel`

and a linear output, an
adjoint variable can be used to speed up the computation of the gradient
(see `_compute_output_d_mu`

).

#### Neural network reductor for non-stationary problems¶

A reductor based on neural networks which deals with non-stationary problems was added in [#1120]. The implementation is an extension of the already existing approach for stationary problems in pyMOR. Here, the time component is treated as an ordinary parameter. The usage of the newly introduced reductor is presented in a corresponding demo where a Burgers’ type equation is solved. As in the stationary case, the implementation allows for several customizations regarding the network architecture and training parameters.

To make training of neural networks more robust, the available data is now shuffled randomly before splitting it into training and validation set [#1175].

#### New tutorials¶

A new tutorial on using pyMOR for accelerating the solution of linear PDE-constrained optimization problems has been added with [#1205]. This tutorial showcases the new features added in [#1110] and also discusses general questions on using model order reduction for a class of optimization problems.

The tutorial ‘Projecting a Model’ explains how to use pyMOR to build an online-efficient reduced order model via (Petrov-)Galerkin projection onto a given reduced space [#1084]. Alongside the mathematical foundation, the user is introduced to the core elements of pyMOR’s internal architecture that realize the projection.

A tutorial on linear time-invariant systems was added and the existing balanced truncation tutorial was appropriately simplified [#1141].

All tutorials now include a ‘launch binder’ button which allows to directly run the tutorial code in the web browser [#1181].

In order to consolidate our documentation all remaining Jupyter notebooks from the `notebooks/`

directory were converted to demo scripts [#1160],
and the `notebooks/`

directory was removed [#1198].

### Additional new features¶

#### Bode plot for input-output systems¶

The `bode_plot`

method for creating a
Bode plot was added [#1051],
complementing the `mag_plot`

method.
Additionally, the `bode`

method can
be used to compute the magnitudes and phases over the imaginary axis (for
continuous-time systems).

#### Iterable VectorArrays¶

`VectorArrays`

became iterable sequences with
[#1068], i.e.,
`for v in V`

can be used to work on individual vectors
(i.e. `VectorArray`

views of length 1) when needed.

#### Expansion of ConcatenationOperators and improved projection algorithms¶

The new `expand`

allows to recursively
expand `concatenations`

of `LincombOperators`

in any given `Model`

or `Operator`

[#1098].
In particular, `expand`

is now used
in `project`

to improve the projection of
such constructs [#1102].
Moreover, several minor improvements have been made to
`project_to_subbasis`

[#1138].

#### Support for Python 3.9¶

### Backward incompatible changes¶

#### Updated Model interface¶

To make the simultaneous computation of multiple `Model`

output quantities such as internal state,
output, or error estimates more efficient and better customizable a `compute`

method was added to the `Model`

interface which is now responsible for the computation of all
relevant data that can be gathered from the simulation of a `Model`

[#1113].
Existing interface methods such as `pymor.models.interface.Model.solve`

or
or `pymor.models.interface.Model.output`

now act as convenience frontends for
`compute`

.
Existing custom `Models`

have to be adapted to the new architecture.

The `estimate`

method has been renamed to `estimate_error`

[#1041].
The old method is deprecated and will be removed in the next release.

Further, to simplify interoperability with third-party packages,
the model outputs, i.e., the results of `output`

,
are no longer generic `VectorArrays`

, but NumPy arrays.
For consistency, `input_space`

and `output_space`

were removed and
`input_dim`

and `output_dim`

were renamed to `dim_input`

and `dim_output`

in `InputOutputModel`

[#1089].

#### Changes in methods for inner products and norms of VectorArrays¶

At first, `VectorArrays`

only had `dot`

and `pairwise_dot`

methods for computing
inner products between vectors.
Later, more general methods `inner`

and `pairwise_inner`

were added to simplify
computing non-Euclidean inner products.
To reduce the list of methods for `VectorArrays`

,
the `dot`

and `pairwise_dot`

methods are now deprecated and will be removed in
the next release [#1066].
In the same vein, the `l2_norm`

and `l2_norm2`

methods are deprecated in favor
of `norm`

and `norm2`

[#1075]
Finally, due to lack of usage and support in some external PDE solvers, the
`l1_norm`

method was deprecated
[#1070].

#### Restructuring of grid classes¶

The inheritance structure of grid classes was simplified [#1044]. In particular,

`ConformalTopologicalGridDefaultImplementations`

,`ReferenceElementDefaultImplementations`

,`AffineGridDefaultImplementations`

, and`ConformalTopologicalGrid`

were removed,`AffineGrid`

was renamed to`Grid`

,`AffineGridWithOrthogonalCenters`

was renamed to`GridWithOrthogonalCenters`

.

#### Renaming of some Operators¶

For consistency in the naming of `Operators`

,
`ComponentProjection`

, `Concatenation`

and `LinearAdvectionLaxFriedrichs`

were
renamed to `ComponentProjectionOperator`

, `ConcatenationOperator`

and
`LinearAdvectionLaxFriedrichsOperator`

, respectively
[#1046].

#### Minimal pip and Manylinux wheel version¶

In order to reduce special casing and infrastructure investment needed for maintaining compatibility with older versions we decided to increase the minimal required pip version to 19.0 (released Jan ‘19) and decided to no longer publish manylinux1 wheels. Pip 19.0 already understands the Manylinux 2010 tag, which going further is the oldest platform we will ship wheels for.

### Further notable improvements¶

[#960] Avoid nested parameter functionals and functions for sums and products

[#1103] Make changing number of POD modes for POD-greedy less error prone

[#1137] Always initialize mass and rhs attributes of InstationaryModel

[#1139] Implement as_source_array/as_range_array for sparse NumpyMatrixOperators

[#1144] Simplify __sub__ for iosys models, check D operator in h2_norm

[#1154] Increase gram_schmidt default reiteration_tol to 9e-1

## pyMOR 2020.1 (July 23, 2020)¶

We are proud to announce the release of pyMOR 2020.1! Highlights of this release are support for non-intrusive model order reduction using artificial neural networks, the subspace accelerated dominant pole algorithm (SAMDP) and the implicitly restarted Arnoldi method for eigenvalue computation. Parameter handling in pyMOR has been simplified, and a new series of hands-on tutorials helps getting started using pyMOR more easily.

Over 600 single commits have entered this release. For a full list of changes see here.

pyMOR 2020.1 contains contributions by Linus Balicki, Tim Keil, Hendrik Kleikamp and Luca Mechelli. We are also happy to welcome Linus as a new main developer! See here for more details.

### Release highlights¶

#### Model order reduction using artificial neural networks¶

With this release, we introduce a simple approach for non-intrusive model order
reduction to pyMOR that makes use of artificial neural networks
[#1001]. The method was first
described in [HU18] and only requires being able to compute solution snapshots of
the full-order `Model`

. Thus, it can be applied to arbitrary (nonlinear) `Models`

even when no
access to the model’s `Operators`

is possible.

Our implementation internally wraps PyTorch for the training and evaluation of the neural networks. No knowledge of PyTorch or neural networks is required to apply the method.

#### New system analysis and linear algebra algorithms¶

The new `eigs`

method
[#880] computes
smallest/largest eigenvalues of an arbitary linear real `Operator`

using the implicitly restarted Arnoldi method [Leh95]. It can also
be used to solve generalized eigenvalue problems.

So far, computing poles of an `LTIModel`

was only supported by its
`poles`

method, which uses a dense eigenvalue
solver and converts the operators to dense matrices.
The new `samdp`

method
[#834] implements the
subspace accelerated dominant pole (SAMDP) algorithm [RM06],
which can be used to compute the dominant poles operators of an
`LTIModel`

with arbitrary (in particular sparse) system `Operators`

without relying on dense matrix operations.

#### Improved parameter handling¶

While pyMOR always had a powerful and flexible system for handling `Parameters`

,
understanding this system was often a challenge for pyMOR newcomers. Therefore,
we have completely overhauled parameter handling in pyMOR, removing some unneeded
complexities and making the nomenclature more straightforward. In particular:

The

`Parameter`

class has been renamed to`Mu`

.`ParameterType`

has been renamed to`Parameters`

. The items of a`Parameters`

dict are the individual*parameters*of the corresponding`ParametricObject`

. The items of a`Mu`

dict are the associated*parameter values*.All parameters are now one-dimensional NumPy arrays.

Instead of manually calling

`build_parameter_type`

in`__init__`

, the`Parameters`

of a`ParametricObject`

are now automatically inferred from the object’s`__init__`

arguments. The process can be customized using the new`parameters_own`

and`parameters_internal`

properties.`CubicParameterSpace`

was renamed to`ParameterSpace`

and is created using`parametric_object.parameters.space(ranges)`

.

Further details can be found in [#923]. Also see [#949] and [#998].

#### pyMOR tutorial collection¶

Hands-on tutorials provide a good opportunity for new users to get started with a software library. In this release a variety of tutorials have been added which introduce important pyMOR concepts and basic model order reduction methods. In particular users can now learn about:

### Additional new features¶

#### Improvements to ParameterFunctionals¶

Several improvements have been made to pyMOR’s `ParameterFunctionals`

:

#### Extended Newton algorithm¶

Finding a proper parameter for the step size in the Newton algorithm can be a difficult task. In this release an Armijo line search algorithm is added which allows for computing adequate step sizes in every step of the iteration. Details about the line search implementation in pyMOR can be found in [#925].

Additionally, new options for determining convergence of the Newton method have been added. It is now possible to choose between the norm of the residual or the update vector as a measure for the error. Information about other noteworthy improvements that are related to this change can be found in [#956], as well as [#932].

#### initial_guess parameter for apply_inverse¶

The `apply_inverse`

and
`apply_inverse_adjoint`

methods of the `Operator`

interface
have gained an additional `initial_guess`

parameter that can be passed to iterative linear solvers.
For nonlinear `Operators`

the initial guess is passed to the `newton`

algorithm [#941].

#### manylinux 2010+2014 wheels¶

In addition to manylinux1 wheels we are now also shipping wheels conforming with the manylinux2010 and manylinux2014 standards. The infrastructure for this was added in [#846].

#### Debugging improvements¶

The `defaults`

decorator has been refactored to make stepping through it
with a debugger faster [#864]. Similar improvements
have been made to `RuleTable.apply`

. The new
`breakpoint_for_obj`

and
`breakpoint_for_name`

methods allow setting conditional
breakpoints in `RuleTable.apply`

that match
specific objects to which the table might be applied [#945].

#### WebGL-based visualizations¶

This release enables our pythreejs-based visualization module for Jupyter Notebook environments by default. It acts as a drop in replacement for the previous default, which was matplotlib based. This new module improves interactive performance for visualizations with a large number of degrees of freedom by utilizing the user’s graphics card via the browser’s WebGL API. The old behaviour can be reactivated using

```
from pymor.basic import *
set_defaults({'pymor.discretizers.builtin.gui.jupyter.get_visualizer.backend': 'MPL'})
```

### Backward incompatible changes¶

#### Renamed interface classes¶

The names of pyMOR’s interface classes have been shortened [#859]. In particular:

`VectorArrayInterface`

,`OperatorInterface`

,`ModelInterface`

were renamed to`VectorArray`

,`Operator`

,`Model`

. The corresponding modules were renamed from`pymor.*.interfaces`

to`pymor.*.interface`

.`BasicInterface`

,`ImmutableInterface`

,`CacheableInterface`

were renamed to`BasicObject`

,`ImmutableObject`

,`CacheableObject`

.`pymor.core.interfaces`

has been renamed to`pymor.core.base`

.

The base classes `OperatorBase`

, `ModelBase`

, `FunctionBase`

were merged into
their respective interface classes [#859],
[#867].

#### Module cleanup¶

Modules associated with pyMOR’s builtin discretization toolkit were moved to the
`pymor.discretizers.builtin`

package [#847].
The `domaindescriptions`

and `functions`

packages were made sub-packages of
`pymor.analyticalproblems`

[#855],
[#858]. The obsolete code in
`pymor.discretizers.disk`

was removed [#856].
Further, the `playground`

package was removed [#940].

#### State ids removed and caching simplified¶

The unnecessarily complicated concept of *state ids*, which was used to build cache keys
based on the actual state of a `CacheableObject`

, has been completely removed from pyMOR.
Instead, now a `cache_id`

has to be manually specified when persistent caching over multiple
program runs is desired [#841].

#### Further API changes¶

### Further notable improvements¶

[#895] Implement VectorArray.__deepcopy__ via VectorArray.copy(deep=True)

[#919] [reductors.coercive] remove unneccessary initialization in SimpleCoerciveReductor

[#926] [Operators] Speed up apply methods for LincombOperator

[#937] Move NumpyListVectorArrayMatrixOperator out of the playground

[#943] [logger] adds a ctx manager that restores effective level on exit

## pyMOR 2019.2 (December 16, 2019)¶

We are proud to announce the release of pyMOR 2019.2! For this release we have worked hard to make implementing new models and reduction algorithms with pyMOR even easier. Further highlights of this release are an extended VectorArray interface with generic support for complex numbers, vastly extended and improved system-theoretic MOR methods, as well as builtin support for model outputs and parameter sensitivities.

Over 700 single commits have entered this release. For a full list of changes see here.

pyMOR 2019.2 contains contributions by Linus Balicki, Dennis Eickhorn and Tim Keil. See here for more details.

### Release highlights¶

#### Implement new models and reductors more easily¶

As many users have been struggling with the notion of `Discretization`

in pyMOR
and to account for the fact that not every full-order model needs to be a discretized
PDE model, we have decided to rename `DiscretizationInterface`

to
`ModelInterface`

and all deriving classes accordingly
[#568]. Consequently, the variable names
`m`

, `rom`

, `fom`

will now be found throughout pyMOR’s code to refer to an arbitrary
`Model`

, a reduced-order `Model`

or a full-order `Model`

.

Moreover, following the Zen of Python’s
‘Explicit is better than implicit’ and ‘Simple is better than complex’, we have
completely revamped the implementation of `Models`

and `reductors`

to facilitate the implementation of new model types and reduction methods
[#592]. In particular, the complicated
and error-prone approach of trying to automatically correctly project the `Operators`

of any given `Model`

in `GenericRBReductor`

and `GenericPGReductor`

has been replaced
by simple `Model`

-adapted reductors which explicitly state with which bases each
`Operator`

shall be projected. As a consequence, we could remove the `operators`

dict
and the notion of `special_operators`

in `ModelBase`

,
vastly simplifying its implementation and the definition of new `Model`

classes.

#### Extended VectorArray interface with generic complex number support¶

The `VectorArrayInterface`

has been extended to
allow the creation of non-zero vectors using the
`ones`

and
`full`

methods
[#612]. Vectors with random values can
be created using the `random`

method [#618]. All `VectorArray`

implementations shipped with pyMOR support these new interface methods.
As an important step to improve the support for system-theoretic MOR methods with
external PDE solvers, we have implemented facilities to provide generic support
for complex-valued `VectorArrays`

even for PDE solvers that do not support complex
vectors natively [#755].

#### Improved and extended support for system-theoretic MOR methods¶

To increase compatibility between input-output models in
`iosys`

and the `InstationaryModel`

, support for models with
parametric operators has been added
[#626], which also enables
implementation of parametric MOR methods for such models.
Furthermore, the `state_space`

attribute was removed in favor of
`solution_space`

[#648] to make
more explicit the result of the
`solve`

method.
Further improvements in naming has been renaming attributes `n`

, `m`

, and `p`

to
`order`

, `input_dim`

, and `output_dim`

[#578] and the `bode`

method to
`freq_resp`

[#729].
Reductors in `bt`

and `h2`

received
numerous improvements ([#656],
[#661],
[#807]) and variants of one-sided
IRKA have been added [#579].
As for Lyapunov equations, a low-rank solver for Riccati equations has been
added [#736].

#### Model outputs and parameter sensitivities¶

The notion of a `Model`

’s output has been formally added to the
`ModelInterface`

[#750]:
The output of a `Model`

is defined to be a `VectorArray`

of the model’s
`output_space`

`VectorSpace`

and
can be computed using the new `output`

method.
Alternatively, `solve`

method can
now be called with `return_output=True`

to return the output alongside the state space
solution.

To compute parameter sensitivities, we have added `d_mu`

methods to
`OperatorInterface`

and
`ParameterFunctionalInterface`

which return the partial derivative with respect to a given parameter component
[#748].

### Additional new features¶

#### Extended FEniCS bindings¶

FEniCS support has been improved by adding support for nonlinear `Operators`

including
an implementation of `restricted`

to enable fast local evaluation of the operator for efficient
`empirical interpolation`

[#819]. Moreover the parallel implementations
of `amax`

and
`dofs`

have been fixed
[#616] and
`solver_options`

are now correctly
handled in `_assemble_lincomb`

[#812].

#### Improved greedy algorithms¶

pyMOR’s greedy algorithms have been refactored into `weak_greedy`

and `adaptive_weak_greedy`

functions that
use a common `WeakGreedySurrogate`

to estimate
the approximation error and extend the greedy bases. This allows these functions to be
used more flexible, e.g. for goal-oriented basis generation, by implementing a new
`WeakGreedySurrogate`

[#757].

#### Numerical linear algebra algorithms¶

By specifying `return_R=True`

, the `gram_schmidt`

algorithm can now also be used to compute a QR decomposition of a given `VectorArray`

[#577]. Moreover,
`gram_schmidt`

can be used as a more accurate
(but often more expensive) alternative for computing the `pod`

of
a `VectorArray`

. Both, the older method-of-snapshots approach as well as the QR decomposition
are now available for computing a truncated SVD of a `VectorArray`

via the newly added
`svd_va`

module [#718].
Basic randomized algorithms for approximating the image of a linear `Operator`

are
implemented in the `randrangefinder`

module
[#665].

#### Support for low-rank operators¶

Low-rank `Operators`

and as well as sums of arbitrary `Operators`

with a low-rank
`Operator`

can now be represented by `LowRankOperator`

and `LowRankUpdatedOperator`

. For the latter,
`apply_inverse`

and
`apply_inverse_adjoint`

are implemented
via the Sherman-Morrison-Woodbury formula [#743].

#### Improved string representations of pyMOR objects¶

Custom `__str__`

special methods have been implemented for all `Model`

classes shipped with
pyMOR [#652]. Moreover, we have added a generic
`__repr__`

implementation to `BasicInterface`

which recursively prints all class attributes
corresponding to an `__init__`

argument (with a non-default value)
[#706].

#### Easier working with immutable objects¶

A new check in `ImmutableMeta`

enforces all `__init__`

arguments
of an `immutable`

object to be available as object attributes, thus ensuring that
`~pymor.core.interfaces.ImmutableInterface.with_`

works reliably with all `immutable`

objects
in pyMOR [#694]. To facilitate the initialization
of these attributes in `__init__`

the
__auto_init
method has been added to `BasicInterface`

[#732].
Finally, `~pymor.core.interfaces.ImmutableInterface.with_`

now has a `new_type`

parameter
which allows to change the class of the object returned by it
[#705].

#### project and assemble_lincomb are easier to extend¶

In pyMOR 0.5, we have introduced `RuleTables`

to make central algorithms in
pyMOR, like the projection of an `Operator`

via `project`

, easier to trace and
extend.
For pyMOR 2019.2, we have further simplified `project`

by removing the `product`

argument from the underlying `RuleTable`

[#785].
As the inheritance-based implementation of `assemble_lincomb`

was showing similar
complexity issues as the old inheritance-based implementation of `projected`

, we
moved all backend-agnostic logic into the `RuleTable`

-based free function
`assemble_lincomb`

, leaving the remaining backend
code in `_assemble_lincomb`

[#619].

#### Improvements to pyMOR’s discretization toolbox¶

pyMOR’s builtin discretization toolbox as seen multiple minor improvements:

### Backward incompatible changes¶

#### Dropped Python 3.5 support¶

As Python 3.6 or newer now ships with the current versions of all major Linux distributions, we have decided to drop support for Python 3.6 in pyMOR 2019.2. This allows us to benefit from new language features, in particular f-strings and class attribute definition order preservation [#553], [#584].

#### Global RandomState¶

pyMOR now has a (mutable) global default `RandomState`

. This means
that when `sample_randomly`

is called
repeatedly without specifying a `random_state`

or `seed`

argument, different `Parameter`

samples will be returned in contrast to the (surprising) previous behavior where the
same samples would have been returned. The same `RandomState`

is
used by the newly introduced `random`

method of the `VectorArrayInterface`

[#620].

#### Space id handling¶

The usage of `VectorSpace`

`ids`

in pyMOR
has been reduced throughout pyMOR to avoid unwanted errors due to incompatible `VectorSpaces`

(that only differ by their id):

#### Further API Changes¶

The stagnation criterion of the

`newton`

is disabled by default (and a relaxation parameter has been added) [#800].The

`coordinates`

parameter of`ProjectionParameterFunctional`

has been renamed to`index`

[#756].

### Further notable improvements¶

[#608] [mpi] small tweaks to make MPI wrapping more flexible

[#627] Fix as_source_array/as_range_array for BlockRowOperator/BlockColumnOperator

[#702] Add ‘linear’ attribute to StationaryModel and InstationaryModel

[#789] allow time-dep operator or rhs in ParabolicRBReductor

[#791] Add rule to ProjectRules for the case that source_basis range basis are None

[#814] [algorithms.image] fix CollectVectorRangeRules for ConcatenationOperator

[#815] Make assumptions on mass Operator in InstationaryModel consistent

[#824] Fix NumpyVectorArray.__mul__ when other is a NumPy array

[#827] Add Gitlab Pages hosting for docs + introduce nbplots for sphinx

## pyMOR 0.5 (January 17, 2019)¶

After more than two years of development, we are proud to announce the release
of pyMOR 0.5! Highlights of this release are support for Python 3, bindings for
the NGSolve finite element library, new linear algebra algorithms, various
`VectorArray`

usability improvements, as well as a redesign of pyMOR’s
projection algorithms based on `RuleTables`

.

Especially we would like to highlight the addition of various system-theoretic
reduction methods such as Balanced Truncation or IRKA. All algorithms are
implemented in terms of pyMOR’s `Operator`

and `VectorArray`

interfaces,
allowing their application to any model implemented using one of the PDE solver
supported by pyMOR. In particular, no import of the system matrices is
required.

Over 1,500 single commits have entered this release. For a full list of changes see here.

pyMOR 0.5 contains contributions by Linus Balicki, Julia Brunken and Christoph Lehrenfeld. See here for more details.

### Release highlights¶

#### Python 3 support¶

pyMOR is now compatible with Python 3.5 or greater. Since the use of Python 3 is
now standard in the scientific computing community and security updates for
Python 2 will stop in less than a year (https://pythonclock.org), we decided to
no longer support Python 2 and make pyMOR 0.5 a Python 3-only release. Switching
to Python 3 also allows us to leverage newer language features such as the `@`

binary operator for concatenation of `Operators`

, keyword-only arguments or
improved support for asynchronous programming.

#### System-theoretic MOR methods¶

With 386 commits, [#464] added
systems-theoretic methods to pyMOR. Module `pymor.discretizations.iosys`

contains new discretization classes for input-output systems, e.g. `LTISystem`

,
`SecondOrderSystem`

and `TransferFunction`

. At present, methods related to these
classes mainly focus on continuous-time, non-parametric systems.

Since matrix equation solvers are important tools in many system-theoretic
methods, support for Lyapunov, Riccati and Sylvester equations has been added in
`pymor.algorithms.lyapunov`

, `pymor.algorithms.riccati`

and
`pymor.algorithms.sylvester`

. A generic low-rank ADI (Alternating Direction
Implicit) solver for Lyapunov equations is implemented in
`pymor.algorithms.lradi`

. Furthermore, bindings to low-rank and dense
solvers for Lyapunov and Riccati equations from `SciPy`

,
Slycot and
Py-M.E.S.S. are provided in
`pymor.bindings.scipy`

, `pymor.bindings.slycot`

and
`pymor.bindings.pymess`

. A generic Schur decomposition-based solver for
sparse-dense Sylvester equations is implemented in
`pymor.algorithms.sylvester`

.

Balancing Truncation (BT) and Iterative Rational Krylov Algorithm (IRKA) are
implemented in `BTReductor`

and
`IRKAReductor`

. LQG and Bounded Real variants of BT
are also available (`LQGBTReductor`

,
`BRBTReductor`

). Bitangential Hermite interpolation
(used in IRKA) is implemented in
`LTI_BHIReductor`

. Two-Sided Iteration
Algorithm (TSIA), a method related to IRKA, is implemented in
`TSIAReductor`

.

Several structure-preserving MOR methods for second-order systems have been
implemented. Balancing-based MOR methods are implemented in
`pymor.reductors.sobt`

, bitangential Hermite interpolation in
`SO_BHIReductor`

and Second-Order Reduced
IRKA (SOR-IRKA) in `SOR_IRKAReductor`

.

For more general transfer functions, MOR methods which return `LTISystems`

are
also available. Bitangential Hermite interpolation is implemented in
`TFInterpReductor`

and Transfer Function
IRKA (TF-IRKA) in `TF_IRKAReductor`

.

Usage examples can be found in the `heat`

and `string_equation`

demo scripts.

#### NGSolve support¶

We now ship bindings for the NGSolve finite element
library. Wrapper classes for `VectorArrays`

and matrix-based `Operators`

can be
found in the `pymor.bindings.ngsolve`

module. A usage example can be found
in the `thermalblock_simple`

demo script.

#### New linear algebra algorithms¶

pyMOR now includes an implementation of the
HAPOD algorithm for fast distributed
or incremental computation of the Proper Orthogonal Decomposition
(`pymor.algorithms.hapod`

). The code allows for arbitrary sub-POD trees,
on-the-fly snapshot generation and shared memory parallelization via
`concurrent.futures`

. A basic usage example can be found in the `hapod`

demo script.

In addition, the Gram-Schmidt biorthogonalization algorithm has been included in
`pymor.algorithms.gram_schmidt`

.

#### VectorArray improvements¶

`VectorArrays`

in pyMOR have undergone several usability improvements:

The somewhat dubious concept of a

`subtype`

has been superseded by the concept of`VectorSpaces`

which act as factories for`VectorArrays`

. In particular, instead of a`subtype`

,`VectorSpaces`

can now hold meaningful attributes (e.g. the dimension) which are required to construct`VectorArrays`

contained in the space. The`id`

attribute allows to differentiate between technically identical but mathematically different spaces [#323].`VectorArrays`

can now be indexed to select a subset of vectors to operate on. In contrast to advanced indexing in`NumPy`

, indexing a`VectorArray`

will always return a view onto the original array data [#299].New methods with clear semantics have been introduced for the conversion of

`VectorArrays`

to (`to_numpy`

) and from (`from_numpy`

)`NumPy arrays`

[#446].Inner products between

`VectorArrays`

w.r.t. to a given inner product`Operator`

or their norm w.r.t. such an operator can now easily be computed by passing the`Operator`

as the optional`product`

argument to the new`inner`

and`norm`

methods [#407].The

`components`

method of`VectorArrays`

has been renamed to the more intuitive name`dofs`

[#414].The

`l2_norm2`

and`norm2`

have been introduced to compute the squared vector norms [#237].

#### RuleTable based algorithms¶

In pyMOR 0.5, projection algorithms are implemented via recursively applied
tables of transformation rules. This replaces the previous inheritance-based
approach. In particular, the `projected`

method to perform a (Petrov-)Galerkin
projection of an arbitrary `Operator`

has been removed and replaced by a free
`project`

function. Rule-based algorithms are implemented by deriving from the
`RuleTable`

base class [#367],
[#408].

This approach has several advantages:

Rules can match based on the class of the object, but also on more general conditions, e.g. the name of the

`Operator`

or being linear and non-`parametric`

.The entire mathematical algorithm can be specified in a single file even when the definition of the possible classes the algorithm can be applied to is scattered over various files.

The precedence of rules is directly apparent from the definition of the

`RuleTable`

.Generic rules (e.g. the projection of a linear non-

`parametric`

`Operator`

by simply applying the basis) can be easily scheduled to take precedence over more specific rules.Users can implement or modify

`RuleTables`

without modification of the classes shipped with pyMOR.

### Additional new features¶

Reduction algorithms are now implemented using mutable reductor objects, e.g.

`GenericRBReductor`

, which store and`extend`

the reduced bases onto which the model is projected. The only return value of the reductor’s`reduce`

method is now the reduced discretization. Instead of a separate reconstructor, the reductor’s`reconstruct`

method can be used to reconstruct a high-dimensional state-space representation. Additional reduction data (e.g. used to speed up repeated reductions in greedy algorithms) is now managed by the reductor [#375].Linear combinations and concatenations of

`Operators`

can now easily be formed using arithmetic operators [#421].The handling of complex numbers in pyMOR is now more consistent. See [#458], [#362], [#447] for details. As a consequence of these changes, the

`rhs`

`Operator`

in`StationaryDiscretization`

is now a vector-like`Operator`

instead of a functional.The analytical problems and discretizers of pyMOR’s discretization toolbox have been reorganized and improved. All problems are now implemented as instances of

`StationaryProblem`

or`InstationaryProblem`

, which allows an easy exchange of data`Functions`

of a predefined problem with user-defined`Functions`

. Affine decomposition of`Functions`

is now represented by specifying a`LincombFunction`

as the respective data function [#312], [#316], [#318], [#337].The

`pymor.core.config`

module allows simple run-time checking of the availability of optional dependencies and their versions [#339].Packaging improvements

A compiler toolchain is no longer necessary to install pyMOR as we are now distributing binary wheels for releases through the Python Package Index (PyPI). Using the

`extras_require`

mechanism the user can select to install either a minimal set:pip install pymor

or almost all, including optional, dependencies:

pip install pymor[full]

A docker image containing all of the discretization packages pyMOR has bindings to is available for demonstration and development purposes:

docker run -it pymor/demo:0.5 pymor-demo -h docker run -it pymor/demo:0.5 pymor-demo thermalblock --fenics 2 2 5 5

### Backward incompatible changes¶

`dim_outer`

has been removed from the grid interface [#277].All wrapper code for interfacing with external PDE libraries or equation solvers has been moved to the

`pymor.bindings`

package. For instance,`FenicsMatrixOperator`

can now be found in the`pymor.bindings.fenics`

module. [#353]The

`source`

and`range`

arguments of the constructor of`ZeroOperator`

have been swapped to comply with related function signatures [#415].The identifiers

`discretization`

,`rb_discretization`

,`ei_discretization`

have been replaced by`d`

,`rd`

,`ei_d`

throughout pyMOR [#416].The

`_matrix`

attribute of`NumpyMatrixOperator`

has been renamed to`matrix`

[#436]. If`matrix`

holds a`NumPy array`

this array is automatically made read-only to prevent accidental modification of the`Operator`

[#462].The

`BoundaryType`

class has been removed in favor of simple strings [#305].The complicated and unused mapping of local parameter component names to global names has been removed [#306].

### Further notable improvements¶

[#315] [functions] some improvements to ExpressionFunction/GenericFunction.

[#346] Implement more arithmetic operations on VectorArrays and Operators.

[#369] Add basic support for visualization in juypter notebooks.

[#422] [Concatenation] allow more than two operators in a Concatenation.

[#438] Fix VectorArrayOperator, generalize as_range/source_array.

[#441] fix #439 (assemble_lincomb “operators” parameter sometimes list, sometimes tuple).

[#481] [project] ensure solver_options are removed from projected operators.

[#488] [operators.block] add BlockRowOperator, BlockColumnOperator.

[#497] Support automatic conversion of InstationaryDiscretization to LTISystem.

## pyMOR 0.4 (September 28, 2016)¶

With the pyMOR 0.4 release we have changed the copyright of pyMOR to

Copyright 2013-2016 pyMOR developers and contributors. All rights reserved.

Moreover, we have added a Contribution guideline to help new users with starting to contribute to pyMOR. Over 800 single commits have entered this release. For a full list of changes see here. pyMOR 0.4 contains contributions by Andreas Buhr, Michael Laier, Falk Meyer, Petar Mlinarić and Michael Schaefer. See here for more details.

### Release highlights¶

#### FEniCS and deal.II support¶

pyMOR now includes wrapper classes for integrating PDE solvers
written with the `dolfin`

library of the FEniCS
project. For a usage example, see `pymordemos.thermalblock_simple.discretize_fenics`

.
Experimental support for deal.II can be
found in the pymor-deal.II
repository of the pyMOR GitHub organization.

#### Parallelization of pyMOR’s reduction algorithms¶

We have added a parallelization framework to pyMOR which allows
parallel execution of reduction algorithms based on a simple
`WorkerPool`

interface [#14].
The `greedy`

[#155]
and `ei_greedy`

algorithms [#162]
have been refactored to utilize this interface.
Two `WorkerPool`

implementations are shipped with pyMOR:
`IPythonPool`

utilizes the parallel
computing features of IPython, allowing
parallel algorithm execution in large heterogeneous clusters of
computing nodes. `MPIPool`

can be used
to benefit from existing MPI-based parallel HPC computing architectures
[#161].

#### Support classes for MPI distributed external PDE solvers¶

While pyMOR’s `VectorArray`

, `Operator`

and `Discretization`

interfaces are agnostic to the concrete (parallel) implementation
of the corresponding objects in the PDE solver, external solvers
are often integrated by creating wrapper classes directly corresponding
to the solvers data structures. However, when the solver is executed
in an MPI distributed context, these wrapper classes will then only
correspond to the rank-local data of a distributed `VectorArray`

or
`Operator`

.

To facilitate the integration of MPI parallel solvers, we have added
MPI helper classes [#163]
in `pymor.vectorarrays.mpi`

, `pymor.operators.mpi`

and `pymor.discretizations.mpi`

that allow an automatic
wrapping of existing sequential bindings for MPI distributed use.
These wrapper classes are based on a simple event loop provided
by `pymor.tools.mpi`

, which is used in the interface methods of
the wrapper classes to dispatch into MPI distributed execution
of the corresponding methods on the underlying MPI distributed
objects.

The resulting objects can be used on MPI rank 0 (including interactive
Python sessions) without any further changes to pyMOR or the user code.
For an example, see `pymordemos.thermalblock_simple.discretize_fenics`

.

#### New reduction algorithms¶

`adaptive_greedy`

uses adaptive parameter training set refinement according to [HDO11] to prevent overfitting of the reduced model to the training set [#213].`reduce_parabolic`

reduces linear parabolic problems using`reduce_generic_rb`

and assembles an error estimator similar to [GP05], [HO08]. The`parabolic_mor`

demo contains a simple sample application using this reductor [#190].The

`estimate_image`

and`estimate_image_hierarchical`

algorithms can be used to find an as small as possible space in which the images of a given list of operators for a given source space are contained for all possible parameters`mu`

. For possible applications, see`reduce_residual`

which now uses`estimate_image_hierarchical`

for Petrov-Galerkin projection of the residual operator [#223].

#### Copy-on-write semantics for `VectorArrays`

¶

The `copy`

method
of the `VectorArray`

interface is now assumed to have copy-on-write
semantics. I.e., the returned `VectorArray`

will contain a reference to the same
data as the original array, and the actual data will only be copied when one of
the arrays is changed. Both `NumpyVectorArray`

and `ListVectorArray`

have been
updated accordingly [#55].
As a main benefit of this approach, `immutable`

objects having a `VectorArray`

as
an attribute now can safely create copies of the passed `VectorArrays`

(to ensure
the immutability of their state) without having to worry about unnecessarily
increased memory consumption.

#### Improvements to pyMOR’s discretizaion tookit¶

An unstructured triangular

`Grid`

is now provided by`UnstructuredTriangleGrid`

. Such a`Grid`

can be obtained using the`discretize_gmsh`

method, which can parse Gmsh output files. Moreover, this method can generate`Gmsh`

input files to create unstructured meshes for an arbitrary`PolygonalDomain`

[#9].Basic support for parabolic problems has been added. The

`discretize_parabolic_cg`

and`discretize_parabolic_fv`

methods can be used to build continuous finite element or finite volume`Discretizations`

from a given`pymor.analyticalproblems.parabolic.ParabolicProblem`

. The`parabolic`

demo demonstrates the use of these methods [#189].The

`pymor.discretizers.disk`

module contains methods to create stationary and instationary affinely decomposed`Discretizations`

from matrix data files and an`.ini`

file defining the given problem.`EllipticProblems`

can now also contain advection and reaction terms in addition to the diffusion part.`discretize_elliptic_cg`

has been extended accordingly [#211].The

`continuous Galerkin`

module has been extended to support Robin boundary conditions [#110].`BitmapFunction`

allows to use grayscale image data as data`Functions`

[#194].For the visualization of time-dependent data, the colorbars can now be rescaled with each new frame [#91].

#### Caching improvements¶

`state id`

generation is now based on deterministic pickling. In previous version of pyMOR, the`state id`

of`immutable`

objects was computed from the state ids of the parameters passed to the object’s`__init__`

method. This approach was complicated and error-prone. Instead, we now compute the`state id`

as a hash of a deterministic serialization of the object’s state. While this approach is more robust, it is also slightly more expensive. However, due to the object’s immutability, the`state id`

only has to be computed once, and state ids are now only required for storing results in persistent cache regions (see below). Computing such results will usually be much more expensive than the`state id`

calculation [#106].`CacheRegions`

now have a`persistent`

attribute indicating whether the cache data will be kept between program runs. For persistent cache regions the`state id`

of the object for which the cached method is called has to be computed to obtain a unique persistent id for the given object. For non-persistent regions the object’s`~pymor.core.interfaces.BasicInterface.uid`

can be used instead.`pymor.core.cache_regions`

now by default contains`'memory'`

,`'disk'`

and`'persistent'`

cache regions [#182], [#121] .`defaults`

can now be marked to not affect`state id`

computation. In previous version of pyMOR, changing any`default`

value caused a change of the`state id`

pyMOR’s defaults dictionary, leading to cache misses. While this in general is desirable, as, for instance, changed linear solver default error tolerances might lead to different solutions for the same`Discretization`

object, it is clear for many I/O related defaults, that these will not affect the outcome of any computation. For these defaults, the`defaults`

decorator now accepts a`sid_ignore`

parameter, to exclude these defaults from`state id`

computation, preventing changes of these defaults causing cache misses [#81].As an alternative to using the

`@cached`

decorator,`cached_method_call`

can be used to cache the results of a function call. This is now used in`solve`

to enable parsing of the input parameter before it enters the cache key calculation [#231].

### Additional new features¶

`apply_inverse_adjoint`

has been added to the`Operator`

interface [#133].Support for complex values in

`NumpyVectorArray`

and`NumpyMatrixOperator`

[#131].- New
`ProductParameterFunctional`

. This

`ParameterFunctional`

represents the product of a given list of`ParameterFunctionals`

.

- New
- New
`SelectionOperator`

[#105]. This

`Operator`

represents one`Operator`

of a given list of`Operators`

, depending on the evaluation of a provided`ParameterFunctional`

,

- New
- New block matrix operators [#215].
`BlockOperator`

and`BlockDiagonalOperator`

represent block matrices of`Operators`

which can be applied to appropriately shaped`BlockVectorArrays`

.

`from_file`

factory method for`NumpyVectorArray`

and`NumpyMatrixOperator`

[#118].`NumpyVectorArray.from_file`

and`NumpyMatrixOperator.from_file`

can be used to construct such objects from data files of various formats (MATLAB, matrix market, NumPy data files, text).

`ListVectorArray`

-based`NumpyMatrixOperator`

[#164].The

`playground`

now contains`NumpyListVectorArrayMatrixOperator`

which can apply`NumPy`

/`SciPy`

matrices to a`ListVectorArray`

. This`Operator`

is mainly intended for performance testing purposes. The`thermalblock`

demo now has an option`--list-vector-array`

for using this operator instead of`NumpyMatrixOperator`

.

- Log indentation support [#230].
pyMOR’s log output can now be indented via the

`logger.block(msg)`

context manger to reflect the hierarchy of subalgorithms.

- Default implementation of
`as_vector`

for functionals [#107]. `OperatorBase.as_vector`

now contains a default implementation for functionals by calling`apply_adjoint`

.

- Default implementation of
`pycontracts`

has been removed as a dependency of pyMOR [#127].Test coverage has been raised to 80 percent.

### Backward incompatible changes¶

`VectorArray`

implementations have been moved to the`pymor.vectorarrays`

sub-package [#89].- The
`dot`

method of the`VectorArray`

interface has been split into`dot`

and`pairwise_dot`

[#76]. The

`pairwise`

parameter of`dot`

has been removed, always assuming`pairwise == False`

. The method`pairwise_dot`

corresponds to the`pairwise == True`

case. Similarly the`pariwise`

parameter of the`apply2`

method of the`Operator`

interface has been removed and a`pairwise_apply2`

method has been added.

- The
`almost_equal`

has been removed from the`VectorArray`

interface [#143].As a replacement, the new method

`pymor.algorithms.basic.almost_equal`

can be used to compare`VectorArrays`

for almost equality by the norm of their difference.

`lincomb`

has been removed from the`Operator`

interface [#83].Instead, a

`LincombOperator`

should be directly instantiated.

- Removal of the
`options`

parameter of`apply_inverse`

in favor of`solver_options`

attribute [#122]. The

`options`

parameter of`OperatorInterface.apply_inverse`

has been replaced by the`solver_options`

attribute. This attribute controls which fixed (linear) solver options are used when`apply_inverse`

is called. See here for more details.

- Removal of the
- Renaming of reductors for coercive problems [#224].
`pymor.reductors.linear.reduce_stationary_affine_linear`

and`pymor.reductors.stationary.reduce_stationary_coercive`

have been renamed to`pymor.reductors.coercive.reduce_coercive`

and`pymor.reductors.coercive.reduce_coercive_simple`

. The old names are deprecated and will be removed in pyMOR 0.5.

Non-parametric objects have now

`~pymor.parameters.base.Parametric.parameter_type`

`{}`

instead of`None`

[#84].Sampling methods of

`ParameterSpaces`

now return iterables instead of iterators [#108].- Caching of
`solve`

is now disabled by default [#178]. Caching of

`solve`

must now be explicitly enabled by using`pymor.core.cache.CacheableInterface.enable_caching`

.

- Caching of
The default value for

`extension_algorithm`

parameter of`greedy`

has been removed [#82].- Changes to
`ei_greedy`

[#159], [#160]. The default for the

`projection`

parameter has been changed from`'orthogonal'`

to`'ei'`

to let the default algorithm agree with literature. In addition a`copy`

parameter with default`True`

has been added. When`copy`

is`True`

, the input data is copied before executing the algorithm, ensuring, that the original`VectorArray`

is left unchanged. When possible,`copy`

should be set to`False`

in order to reduce memory consumption.

- Changes to
The

`copy`

parameter of`pymor.algorithms.gram_schmidt.gram_schmidt`

now defaults to`True`

[#123].`with_`

has been moved from`BasicInterface`

to`ImmutableInterface`

[#154].`BasicInterface.add_attributes`

has been removed [#158].- Auto-generated names no longer contain the
`uid`

[#198]. The auto-generated

`~pymor.core.interfaces.BasicInterface.name`

of pyMOR objects no longer contains their`~pymor.core.interfaces.BasicInterface.uid`

. Instead, the name is now simply set to the class name.

- Auto-generated names no longer contain the
- Python fallbacks to Cython functions have been removed [#145].
In order to use pyMOR’s discretization toolkit, building of the

`_unstructured`

,`inplace`

,`relations`

Cython extension modules is now required.

### Further improvements¶

[#156] Let thermal block demo use error estimator by default

[#195] Add more tests / fixtures for operators in pymor.operators.constructions

[#207] No useful error message in case PySide.QtOpenGL cannot be imported

[#209] Allow ‘pip install pymor’ to work even when numpy/scipy are not installed yet

[#269] Provide a helpful error message when cython modules are missing

[#276] Infinite recursion in apply for IdentityOperator * scalar

## pyMOR 0.3 (March 2, 2015)¶

Introduction of the vector space concept for even simpler integration with external solvers.

Addition of a generic Newton algorithm.

Support for Jacobian evaluation of empirically interpolated operators.

Greatly improved performance of the EI-Greedy algorithm. Addition of the DEIM algorithm.

A new algorithm for residual operator projection and a new, numerically stable a posteriori error estimator for stationary coercive problems based on this algorithm. (cf. A. Buhr, C. Engwer, M. Ohlberger, S. Rave, ‘A numerically stable a posteriori error estimator for reduced basis approximations of elliptic equations’, proceedings of WCCM 2014, Barcelona, 2014.)

A new, easy to use mechanism for setting and accessing default values.

Serialization via the pickle module is now possible for each class in pyMOR. (See the new ‘analyze_pickle’ demo.)

Addition of generic iterative linear solvers which can be used in conjunction with any operator satisfying pyMOR’s operator interface. Support for least squares solvers and PyAMG (http://www.pyamg.org/).

An improved SQLite-based cache backend.

Improvements to the built-in discretizations: support for bilinear finite elements and addition of a finite volume diffusion operator.

Test coverage has been raised from 46% to 75%.

Over 500 single commits have entered this release. A full list of all changes can be obtained under the following address: https://github.com/pymor/pymor/compare/0.2.2…0.3.0